allow serialization functions to upgrade warnings to exceptions

[Lance-Drane]

Change Summary

This allows for SchemaSerializer.to_python and SchemaSerializer.to_json to throw a PydanticSerializerError if the user specifies 'error' for the "warnings" parameter and the serialized result does not match the Pydantic core schema.

This change should not break backwards compatibility.

Related issue number

pydantic/pydantic#8978

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @samuelcolvin

[codecov]

Codecov Report

Attention: Patch coverage is 84.44444% with 7 lines in your changes are missing coverage. Please review.

Files	Patch %	Lines
src/serializers/extra.rs	79.41%	7 Missing ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

CodSpeed Performance Report

Merging #1258 will not alter performance

_{Comparing Lance-Drane:main (255e0d7) with main (2e2c139)}

Summary

✅ 155 untouched benchmarks

[Lance-Drane]

please review

[davidhewitt]

Thanks for the PR!

The feature looks well-implemented. I just have one question; why isn't -Werror (or PYTHONWARNINGS environment variable) sufficient for your use case?

[Lance-Drane]

Thanks for the PR!

The feature looks well-implemented. I just have one question; why isn't -Werror (or PYTHONWARNINGS environment variable) sufficient for your use case?

My specific use-case is that I'm writing a library for domain scientists to use as part of integrating into a wider ecosystem. These users may not think to configure Python warning handling themselves through warnings.filterwarnings(), or they may be using other libraries where warnings are expected and not be able to use global compiler CLI flags or environment variables.

The basic user workflow is very similar to FastAPI, but supports multiple protocols and mandates that all entrypoints be able to generate a valid schema. Application authors use the decorator pattern to annotate certain functions on a class which have up to one TypeAdapter-supported request parameter and one TypeAdapter-supported response parameter, and are in charge of the core domain logic themselves, including ensuring that their return type matches their type annotation. Since we also use the emitted types with Pydantic to build a "global" JSON schema, we want to ensure that the type of the values their functions return match the return annotation. (The library use inspect.signature to make sure users include annotations in the first place, and we create TypeAdapters from these annotations.)

So this approach allows users to focus on defining their input/output types (and we allow them to use Pydantic fields and ConfigDicts however they want), while being able to ignore everything from (de)serialization to the transport layer.

The code in the library is fairly straightforward, and looks something like this:

 # variable 'response_type_adapter' is a TypeAdapter, cached from introspection # variable 'user_response' is the return value from the library calling the user's function try: return response_type_adapter.dump_json(user_response, by_alias=True, warnings='error') except PydanticSerializationError as e: logger.error(f"Your function did not return a value matching your response type. {e}") raise SendAResponseError from e

[davidhewitt]

Makes sense.

I'm happy with this getting merged as-is. Thanks! 👍