| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Closes: #1085
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changing this without deprecation is backwards incompatible, so we
re-introduce a warning.
This only applies if you have not configured neither a Registry nor a legacy
RefResolver. Both of the former 2 cases already have 'correct' behavior (the
former will not automatically retrieve references and is not backwards
incompatible as it is a new API, and the latter will do so but is already
fully deprecated by this release).
Cloess: #1089
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new referencing behavior is more correct (which is why it exists),
but also means that even though `RefResolver` was/is untouched, it can
be called now with more subschemas than previously, and in some cases
that tickles this code to blow up (see the closed issue for a specific
example).
We simply now ignore non-strs, as doing so is no more wrong than this
code used to be.
Closes: #1085
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though RefResolutionError is deprecated (and already raises a
suitable warning), this should make some additional code warn rather
than blow up (i.e. if someone is catching RefResolutionError, that code
should continue to work though it will raise a warning).
Users can transition to non-deprecated APIs by directly catching
referencing.exceptions.Unresolvable.
Closes: #1069
|
|\
| |
| |
| |
| | |
ikonst/2023-03-27-unevaluatedProperties-do-not-validate
Don't evaluate properties twice on behalf of `unevaluatedProperties` validation
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3.11 and later allow additional ISO8601 formats in `datetime` module
ISO8601 parsing. These formats are not RFC3339 section 5.6 compliant.
Especially `datetime.date.fromisoformat()` now allows strings like:
* `20230328` (2023-03-28)
* `2022W527` (2023-01-01)
* `2023-W01` (2023-01-02)
* `2023-W13-2` (2023-03-28)
Fix by doing a regular expression check before passing the value to `datetime`
module. This made the original `.isascii()` check unnecessary.
See:
* https://docs.python.org/3/whatsnew/3.11.html#datetime
* https://github.com/python/cpython/commit/1303f8c927
* https://docs.python.org/3.11/library/datetime.html#datetime.date.fromisoformat
* https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Tests covering the invalid values to be sent to json-schema-org/JSON-Schema-Test-Suite
Fixes #1056.
|
|
|
|
| |
(This could previously be None incorrectly).
|
|
|
|
|
| |
This should re-enable validating from a thread other than the one that
originall imported jsonschema.
|
|
|
| |
Draft202012Validator.validate instead of Draft20212Validator.validate
|
| |
|
| |
|
|
|
|
| |
(We no longer support it.)
|
| |
|
|
|
|
| |
This is specified behavior, see json-schema-org/JSON-Schema-Test-Suite#643.
|
|
|
|
|
|
|
|
| |
We're not a general class, so we know what fields we need
ahead of time.
This seems to give ~15% speedup on Validator evolution, which
happens often as part of walking up and down schemas.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* RefResolutionError is deprecated entirely.
Use referencing.Registry-based APIs, and catch
referencing.exceptions.Unresolvable if you really want to ignore
referencing related issues.
* FormatError should now be imported from jsonschema.exceptions
only, not from the package root.
* ErrorTree should now be imported from jsonschema.exceptions
only, not from the package root.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes: #523
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passes all the remaining referencing tests across all drafts, hooray!
Makes Validators take a referencing.Registry argument which users should
use to customize preloaded schemas, or to configure remote reference
retrieval.
This fully obsoletes jsonschema.RefResolver, which has already been
deprecated in a previous commit. Users should move to instead loading
schemas into referencing.Registry objects.
See the referencing documentation at https://referencing.rtfd.io/ for
details (with more jsonschema-specific information to be added shortly).
Note that the interface for resolving references on a Validator is not
yet public (and hidden behind _resolver and _validate_reference
attributes). One or both of these are likely to become public after some
period of stabilization.
Feedback is of course welcome!
|
|
|
|
|
|
|
|
|
|
|
| |
Makes way for our newer resolver to live in the shorter name.
(This should have no effect on the public API, where we have
Validator.resolver returning this attribute after emitting a deprecation
warning.)
Also bumps the minimum attrs version we depend on, as we need the alias
functionality.
|
|
|
|
| |
Just avoids a deprecation warning when we switch over.
|
|
|
|
|
| |
It will imminently be replaced by referencing.Registry-based
resolution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will make it easier to swap over to referencing's
Resolver (while preserving backwards compat for anyone who
passes a RefResolver to a Validator).
At some point in the future this method may become public
(which will make it easier for external dialects to resolve
references) but let's keep it private for a bit until it's
clear that the interface is stable -- a future draft might
do crazy things like have adjacent properties to $ref affect
the resolution behavior, which would make this method need to
take more than just the $ref value.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Internal uses of it will be removed, replaced with referencing's
resolution APIs, though RefResolver will continue to function during
its deprecation period.
|
|
|
|
| |
Still will be tweaked as the referencing library's public API changes.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
PEP 393 removed narrow builds way back in 3.3.
|
|\
| |
| | |
Add annotations for `_Error`
|
| | |
|
| | |
|
| | |
|
| | |
|