additionalProperties=true

[rafalkrupinski]

From my experience using pydantic will give you a hard time with additionalProperties (defaulting to True even), as it will allow the data to overwrite the Models methods/properties/attributes, requiring a default of Extra.ignore. I consider additionalProperties:True a specification insanity and not worth supporting, sticking with pydantic.

A different use of additionalProperties - dynamic map. https://swagger.io/docs/specification/data-models/dictionaries/

    type: object
    additionalProperties:
      type: string

    {
      "en": "English",
      "fr": "French"
    }

which is rather helpful.

The problem already starts here. You could map it to a simple dict[str,str] but that's not forwards-compatible.
Schema author can add non-required non-string property, which would be a compatible change, but the python API would change in an incompatible way (no longer a dict).
Can't use rooted pydantic model either, as you can't add fields to it.

Perhaps this:

A1:
  type: object
  additionalProperties:
    type: string
A2:
  type: object
  properties:
    a:
      type: string
  additionalProperties:
    type: string

A1=dict[str, str]

class M(dict[str,str]):
    def __init__(self, *, a:int, **kwargs):
        super().__init__(**kwargs)
        self.a=a

It requires (get/set)(attr/item), otherwise you could get duplicates in dict&dict, but I think it keeps the semantics of the schema, should work with code completion as intended, and if schema changes from A1 to A2, the code also remains compatible.

I guess you were right about limitations of pydantic model 🤷🏻

I think not supporting additionalProperties=True is a good decision, as it's impossible to decode such data to a concrete class.

Replying to myself: on the other hand, I have a case, where I'm receiving data from one service and just passing it to another. No need to look inside. Also cases where fields are known only at runtime. Cancel the above, not a good decision.

One could hide the unknowns in .__dict__, but … lax input data validation does not improve things …

No need, python object is just a fancy dict, you can assign stuff to any legal name.
You can validate data at pretty much any stage before sending it, whether it model's init or the operation call. Though init is nicer - fail fast.

[commonism]

The problem already starts here. You could map it to a simple dict[str,str] but that's not forwards-compatible. Schema author can add non-required non-string property, which would be a compatible change, but the python API would change in an incompatible way (no longer a dict). Can't use rooted pydantic model either, as you can't add fields to it.

I fly with root , root is required for discriminated models anyway and pydantic v2 is supposed to lift the limitation.
Example for "root cannot be mixed with other fields",

    CheckoutBalanceCheckRequest:
      properties:
        additionalData:
          additionalProperties:
            type: string
          anyOf:
            - $ref: "#/components/schemas/AdditionalData3DSecure"
            - $ref: "#/components/schemas/AdditionalDataAirline"
          type: object

https://github.com/APIs-guru/openapi-directory/blob/2ac75593089afcacdbefd33c285abc5edac9ec63/APIs/adyen.com/CheckoutService/37/openapi.yaml#L6092

[rafalkrupinski]

I fly with root , root is required for discriminated models anyway and pydantic v2 is supposed to lift the limitation.

I'm not sure if I want to wait for v2 :)
Besides, pydantic is a python validation framework, support for json schema is not the main focus.
I'm happy to use it as long as it lets me write less code and doesn't stand in the way.

Example for "root cannot be mixed with other fields",

I didn't say a schema cannot have properties and combine other schemas, just that pydantic doesn't directly support it.

[rafalkrupinski]

OK, pydantic 2 is here :)
Doesn't allow fields in RootModel

[commonism]

I know. I migrated some time ago.
model_extra is quite useful to work with additionalProperties on non RootModels though.