Schematics

Warnings

• breaking While older documentation mentions support for Python 2.7 and Python 3.3-3.7, the latest `schematics` 2.1.1 explicitly declares `requires_python: >=3.6` on PyPI. Attempting to install or run this version on older Python versions (e.g., Python 2.x, 3.3, 3.4, 3.5) will result in installation failures or runtime errors due to dropped compatibility.
  Fix: Ensure your Python environment is version 3.6 or higher. Upgrade Python or use a virtual environment configured with a supported Python version.
• gotcha The official documentation for Schematics (e.g., on Read the Docs) explicitly states that it is 'currently somewhat out of date.' This can lead to discrepancies between the documented behavior, available features, or best practices and the actual state of the 2.1.1 release.
  Fix: For critical information, complex use cases, or troubleshooting, cross-reference the documentation with the library's GitHub issues, PyPI description, and the source code for the most current and accurate details.
• gotcha When running on Python 3.10 and newer, `schematics` may emit `DeprecationWarning` messages, typically related to deprecated imports from `collections.abc` (e.g., `collections.Iterable`). While these are currently warnings, they indicate usage of Python APIs that are slated for removal in future Python versions (e.g., Python 3.12+), which could eventually lead to breaking errors.
  Fix: Monitor the `schematics` GitHub repository for updates that address these deprecations. For now, acknowledge the warnings; if they are disruptive in non-critical environments, consider temporarily suppressing `DeprecationWarning`s, but be aware of the potential for future compatibility issues.
• gotcha For handling validation failures, `schematics.exceptions.DataError` is the general exception to catch for all validation-related issues from models. While some older examples or specific scenarios might refer to `schematics.exceptions.ModelValidationError`, `ModelValidationError` is a subclass of `DataError`. Using `DataError` ensures you catch all relevant validation exceptions consistently.
  Fix: Always catch `schematics.exceptions.DataError` to handle general model validation failures, as it acts as the base class for other, more specific validation exceptions.

Install

• pip install schematics Install stable version

Imports

• Model

  from schematics.models import Model

• StringType

  from schematics.types import StringType

• URLType

  from schematics.types import URLType

• DecimalType

  from schematics.types import DecimalType

• DateTimeType

  from schematics.types import DateTimeType

• DataError

  from schematics.exceptions import DataError

Quickstart

This quickstart defines a `WeatherReport` model with city (required string), temperature (required decimal), and a default `taken_at` (datetime). It demonstrates successful model instantiation and validation, along with catching `DataError` exceptions for invalid data types and missing required fields.

import datetime
from schematics.models import Model
from schematics.types import StringType, DecimalType, DateTimeType
from schematics.exceptions import DataError

class WeatherReport(Model):
    city = StringType(required=True)
    temperature = DecimalType(required=True)
    taken_at = DateTimeType(default=datetime.datetime.now)

# Create a valid instance
report_data = {'city': 'NYC', 'temperature': 80.5}
t1 = WeatherReport(report_data)
t1.validate()
print(f"Validated report: {t1.to_primitive()}\n")

# Demonstrate validation failure with invalid type
t_fail_type = WeatherReport({'city': 'LA', 'temperature': 'not-a-number'})
try:
    t_fail_type.validate()
except DataError as e:
    print(f"Validation failed (invalid type): {e.messages}")

# Example with missing required field
t_missing_field = WeatherReport({'temperature': 75.0})
try:
    t_missing_field.validate()
except DataError as e:
    print(f"Validation failed (missing field): {e.messages}")