[sydney-runkle]

Marked as experimental in the docs: https://docs.pydantic.dev/latest/api/config/#pydantic.config.ConfigDict.schema_generator

There are lots of things that can simply be done by overriding __get_pydantic_core_schema__ on a model class or using a custom type with a custom core schema.

There are a few things that were advantageous about this approach, like being able to customize how unknown type schemas were handled. That being said, I think we should:

1. In the short term, add explicit support for these use cases
2. In the long term, solidify the API for core schema generation such that we can support and document stable ways to customize schema at the model level.

[cloudflare-workers-and-pages]

Deploying pydantic-docs with    Cloudflare Pages

Latest commit:	0290d67
Status:	✅  Deploy successful!
Preview URL:	https://e24b6160.pydantic-docs.pages.dev
Branch Preview URL:	https://no-gen-schema-customization.pydantic-docs.pages.dev

View logs

[codspeed]

CodSpeed Performance Report

Merging #10303 will not alter performance

_{Comparing no-gen-schema-customization (0290d67) with main (cb8d300)}

Summary

✅ 50 untouched benchmarks

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
pydantic
__init__.py					399
config.py
type_adapter.py
pydantic/_internal
_generate_schema.py
Project Total

This report was generated by python-coverage-comment-action

[Viicos]

But I'm wondering, what was the purpose of creating new instances, if every attribute was being passed in?

Apart from field_name_stack where a new instance is created. By the way, doesn't that break anything?

[sydney-runkle]

The purpose of creating new instances was to give the model a change to inject its custom core schema generator (some subclass of GenerateSchema).

Re field_name_stack - I believe it continues to operate as expected.

[Viicos]

In theory this can lead to inconsistent state, where in the process of generating a core schema for a field (and thus having one field name in the stack), we end up generating something else. However, the field names are only used when generating schema for *Validator classes, that can only be used when defining a field (meaning a new field name will be added to the stack, so it doesn't matter if the stack was reset or not).

[sydney-runkle]

Hmm. Interesting. Not sure I follow entirely - happy to take a closer look together and potentially refactor that structure.

[Viicos]

For instance:

class Sub(BaseModel):
    f: 'Forward'

Forward = int

class Model(BaseModel):
    sub: Sub

When Sub is defined, schema generation fails because Forward isn't defined. when Model.sub is being defined, the field name stack is ['sub']. We try to get the core schema of Sub but it needs to be rebuilt. Previous to your change, we would create a new GenerateSchema instance with an empty field name stack. But now, we build the core schema of Sub with the same instance. When we try to build the core schema of Sub.f, the field name stack is ['sub', 'f'], so it is still valid. It can be inconsistent if we try to build something not related to a field in Sub (e.g. evaluating the type annotation of __pydantic_extra__, etc), but anyway the field name stack is only used by *Validator classes and such classes could only be used (in our example) in the context of field f, so the field name stack would be ['sub', 'f'] so all good.

[adriangb]

looks good to me!

[Viicos]

In theory this can lead to inconsistent state, where in the process of generating a core schema for a field (and thus having one field name in the stack), we end up generating something else. However, the field names are only used when generating schema for *Validator classes, that can only be used when defining a field (meaning a new field name will be added to the stack, so it doesn't matter if the stack was reset or not).

[KotlinIsland]

hey, just thought i would drop in with my usecase of schema_generator/GenerateSchema, i need to deal with an api where there are many uncomfortable features that affect the entire api surface:

• boolean values are represented with an "X" for True, and are not present at all for False
• time/date/datetimes all use consistent, yet non-standard formatting, and return "--" instead of null