Initial Checks

• I confirm that I'm using Pydantic V2

Description

Pydantic has a serialization concept calledserialize as any, which can be enabled globally during serialization (using theserialize_as_any parameter) or per field (using theSerializeAsAny annotation). When used, Pydantic treats the type annotation of the field as if it wereAny, and tries to infer the value using its actual type (see thedocumentation for more details).

Up until now, theserialize_as_any flag andSerializeAsAny annotation were behaving quite differently, and they wereunified in 2.12 (actually, theserialize_as_any flag behavior was aligned to match theSerializeAsAny annotation).

Unfortunately this also led to regressions where cases that previously serialized in 2.11 no longer serialize in 2.12, because dropping the type information forcespydantic-core to use type inference, and not all types have built-in inference inpydantic-core:

frompydanticimportBaseModel,IPvAnyAddressclassBugReproModel(BaseModel):ip_address:IPvAnyAddressbug=BugReproModel(ip_address="192.168.1.1")json_data=bug.model_dump_json(serialize_as_any=True)# PydanticSerializationError: Unable to serialize unknown type: <class 'ipaddress.IPv4Address'>

If you are using theserialize_as_any flag and encountering serialization errors in 2.12:

1. Check if you can make use of theSerializeAsAny annotation instead, and apply it only on fields if this is necessary.
2. If you don't control the types you are serializing (e.g. a Pydantic model defined in a third party library), we'd like to know more about yourserialize_as_any usage. If you use it to achieveduck typing serialization of subclasses, we may introduce a new value forserialize_as_any(e.g. a literal'subclasses', name TBD), on top of the existingTrue/False. Please share use cases in this issue so that we can decide on the best path to take.
3. If you encountered issues with types such asIPvAnyAddress, we are looking into improving our type inference logic to support these whenserialize as any behavior is applied (see below).

In terms of type inference, we should define more precisely howpydantic-core performs it and expand its functionality to cover as many types as possible.

There are various ways thatpydantic-core can currently perform type inference:

• built-in types such as lists, mappings, integers etc
• objects which have a__pydantic_serializer__ attribute (and are not type objects) will use that serializer

I can think of at least two more ways which users would reasonably expectpydantic-core to perform type inference:

• objects which have a__get_pydantic_core_schema__ attribute (and are not type objects) could generate a new serializer from it (this would increase coupling betweenpydantic andpydantic-core, needs design, challenges as always are config and caching)
• for the case ofSerializeAsAny annotation andserialize_as_any runtime flag, thereis type information which we could use to generate a fallback serializer if inference fails