Nti.schema

Latest version: v1.15.1

Safety actively analyzes 628918 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 5

1.12.0

===================

- JSON schemas report the schema for ``IObject`` fields
and the schemas for the possible fields in ``IVariant``.

- Fields in JSON schemas may specify a JSON-serializable dictionary
to be passed as the ``application_info`` schema value. See `issue 44
<https://github.com/NextThought/nti.schema/issues/44>`_.

- JSON schemas now output more constraints automatically. See `issue
47 <https://github.com/NextThought/nti.schema/pull/48>`_.

1.11.0

===================

- JSON schemas now include nested ``value_type`` and ``key_type`` for
collection and mapping fields. See `issue 42
<https://github.com/NextThought/nti.schema/issues/42>`_.

- JSON schemas now include (translated) ``title`` and ``description``
values for fields. See `issue 41
<https://github.com/NextThought/nti.schema/issues/41>`_.

1.10.0

===================

- Add ``nti.schema.fieldproperty.field_name`` to compensate for the
mangling that ``FieldPropertyStoredThroughField`` does.

1.9.2

==================

- Fix ``Variant`` and other implementations of ``IFromObject`` to stop
passing known non-text values to ``fromUnicode`` methods. This only
worked with certain fields (such as ``zope.schema.Number``) that
could accept non-text values, usually by implementation accident,
and could have surprising consequences. Instead, non-text values
will be passed to the ``validate`` method.

- Fix ``Variant`` to stop double-validating values. The underlying
``fromUnicode``, ``fromBytes`` or ``fromObject`` methods were
supposed to already validate.

1.9.1

==================

- Make ``VariantValidationError`` and ``Variant`` have more useful
string representations.

- Make ``fromObject`` methods more gracefully handle an AttributeError
raised by an underlying ``fromUnicode`` method on non-string input
(such as None). This is especially helpful for ``Variant`` fields
because they can catch the error and continue to the next field.

- Fix ``Variant``, ``TupleFromObject``, ``DictFromObject``,
``ListFromObject`` and ``ListOrTupleFromObject`` to allow the
``missing_value`` (which defaults to ``None``) in their
``fromObject`` methods; passing that value in simply returns it
without raising an exception if the field is not required. If the
field is required, a ``RequiredMissing`` is raised. Previously the
sequences raised a ``WrongType`` error, while ``Variant`` *may* or
*may not* have raised an error, depending on the underlying fields
in use.

1.9.0

==================

- ``Variant`` objects now automatically add ``fromObject`` support to
``ICollection`` and ``IMapping`` fields that do not already provide
it, if their ``value_type`` (and ``key_type``) qualify by being
either an ``Object`` field, or something that provides
``IFromObject`` or can be made to, such as a collection or mapping.

Page 2 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.