Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.2k
Don't allow customization ofSchemaGenerator
until interface is more stable#10303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
removing from initfixing config test
cloudflare-workers-and-pagesbot commentedSep 4, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Deploying pydantic-docs with |
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 |
codspeed-hqbot commentedSep 4, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
CodSpeed Performance ReportMerging#10303 willnot alter performanceComparing Summary
|
github-actionsbot commentedSep 4, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Coverage reportClick to see where and how coverage changed
This report was generated bypython-coverage-comment-action |
SchemaGenerator
until interface is more stableSchemaGenerator
until interface is more stableUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
@property | ||
def _current_generate_schema(self) -> GenerateSchema: | ||
cls = self._config_wrapper.schema_generator or GenerateSchema | ||
return cls.__from_parent( | ||
self._config_wrapper_stack, | ||
self._types_namespace_stack, | ||
self.model_type_stack, | ||
self._typevars_map, | ||
self.defs, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
But I'm wondering, what was the purpose of creating new instances, if every attribute was being passed in?
Apart fromfield_name_stack
where a new instance is created. By the way, doesn't that break anything?
sydney-runkleSep 5, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The purpose of creating new instances was to give the model a change to inject its custom core schema generator (some subclass ofGenerateSchema
).
Refield_name_stack
- I believe it continues to operate as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Hmm. Interesting. Not sure I follow entirely - happy to take a closer look together and potentially refactor that structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
For instance:
classSub(BaseModel):f:'Forward'Forward=intclassModel(BaseModel):sub:Sub
WhenSub
is defined, schema generation fails becauseForward
isn't defined. whenModel.sub
is being defined, the field name stack is['sub']
. We try to get the core schema ofSub
but it needs to be rebuilt. Previous to your change, we would create a newGenerateSchema
instance with an empty field name stack. But now, we build the core schema ofSub
with the same instance. When we try to build the core schema ofSub.f
, the field name stack is['sub', 'f']
, so it is still valid. It can be inconsistent if we try to build somethingnot related to a field inSub
(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 fieldf
, so the field name stack would be['sub', 'f']
so all good.
Co-authored-by: Victorien <65306057+Viicos@users.noreply.github.com>
…ntic/pydantic into no-gen-schema-customization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
looks good to me!
@property | ||
def _current_generate_schema(self) -> GenerateSchema: | ||
cls = self._config_wrapper.schema_generator or GenerateSchema | ||
return cls.__from_parent( | ||
self._config_wrapper_stack, | ||
self._types_namespace_stack, | ||
self.model_type_stack, | ||
self._typevars_map, | ||
self.defs, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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).
6db2a0c
intomainUh oh!
There was an error while loading.Please reload this page.
KotlinIsland commentedMar 17, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
hey, just thought i would drop in with my usecase of
|
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: