Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
sydney-runkle merged 13 commits intomainfromno-gen-schema-customization
Sep 5, 2024

Conversation

sydney-runkle
Copy link
Contributor

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.

removing from initfixing config test
@github-actionsgithub-actionsbot added the relnotes-fixUsed for bugfixes. labelSep 4, 2024
@cloudflare-workers-and-pagesCloudflare Workers and Pages
Copy link

cloudflare-workers-and-pagesbot commentedSep 4, 2024
edited
Loading

Deploying pydantic-docs with  Cloudflare Pages  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-hqCodSpeed HQ
Copy link

codspeed-hqbot commentedSep 4, 2024
edited
Loading

CodSpeed Performance Report

Merging#10303 willnot alter performance

Comparingno-gen-schema-customization (0290d67) withmain (cb8d300)

Summary

✅ 50 untouched benchmarks

@github-actionsGitHub Actions
Copy link
Contributor

github-actionsbot commentedSep 4, 2024
edited
Loading

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  pydantic
  __init__.py399
  config.py
  type_adapter.py
  pydantic/_internal
  _generate_schema.py
Project Total 

This report was generated bypython-coverage-comment-action

@sydney-runklesydney-runkle added relnotes-changeUsed for changes to existing functionality which don't have a better categorization. relnotes-performanceUsed for performance improvements. and removed relnotes-fixUsed for bugfixes. labelsSep 4, 2024
@sydney-runklesydney-runkle changed the titleWIP: Don't allow customization ofSchemaGenerator until interface is more stableDon't allow customization ofSchemaGenerator until interface is more stableSep 4, 2024
@sydney-runklesydney-runkle marked this pull request as ready for reviewSeptember 4, 2024 17:30
Comment on lines -409 to -418
@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,
)
Copy link
Member

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?

Copy link
ContributorAuthor

@sydney-runklesydney-runkleSep 5, 2024
edited
Loading

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.

Copy link
Member

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).

sydney-runkle reacted with thumbs up emoji
Copy link
ContributorAuthor

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.

Copy link
Member

@ViicosViicosSep 5, 2024
edited
Loading

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.

Copy link
Member

@adriangbadriangb left a 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!

Comment on lines -409 to -418
@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,
)
Copy link
Member

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).

sydney-runkle reacted with thumbs up emoji
@sydney-runklesydney-runkle merged commit6db2a0c intomainSep 5, 2024
62 checks passed
@sydney-runklesydney-runkle deleted the no-gen-schema-customization branchSeptember 5, 2024 19:49
@KotlinIsland
Copy link
Contributor

KotlinIsland commentedMar 17, 2025
edited
Loading

hey, just thought i would drop in with my usecase ofschema_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" forTrue, and are not present at all forFalse
  • time/date/datetimes all use consistent, yet non-standard formatting, and return"--" instead ofnull

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@ViicosViicosViicos approved these changes

@adriangbadriangbadriangb approved these changes

@samuelcolvinsamuelcolvinAwaiting requested review from samuelcolvin

Assignees
No one assigned
Labels
relnotes-changeUsed for changes to existing functionality which don't have a better categorization.relnotes-performanceUsed for performance improvements.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@sydney-runkle@KotlinIsland@adriangb@Viicos

[8]ページ先頭

©2009-2025 Movatter.jp