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

Add support fortyping.Never#1579

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

Open
changhc wants to merge14 commits intopydantic:main
base:main
Choose a base branch
Loading
fromchanghc:9731-never
Open

Conversation

changhc
Copy link
Contributor

@changhcchanghc commentedDec 10, 2024
edited by pydantic-hookybot
Loading

Change Summary

Add support fortyping.Never.

Validation

The validator implementation might look a bit weird. This is because ofRootModel. Even though it doesn't really make sense, I assume that the following should work:

fromtypingimportNeverfrompydanticimportRootModelv=RootModel[Never]()

and becauseRootModel passesPydanticUndefined to the validator when no data is provided, the validator needs to work withPydanticUndefined. If we don't expectRootModel[Never]() to ever work, we can simplify the implementation and simply reject all values, but there might be another issue: users might wonder how the following works whileRootModel does not:

fromtypingimportNeverfrompydanticimportBaseModelclassModel(BaseModel):a:Never

Also, simply rejecting everything in the validator means that the validated model instance will not contain any value for theNever fields. When users try to access those fields, they will get an error, but the error is going to be something like

AttributeError: 'Model' object has no attribute 'a'

This kind of makes sense because indeed theNever fields never hold any value, but at the same time they are defined in the model, so it kind of makes sense as well to say that the instances do have those attributes. We should provide some better error messages, but before that gets handled in pydantic, I think in core we can returnPydanticUndefined as a placeholder.

Serialisation

Serialising the never fieldsthemselves will trigger an error. For instance,

v=RootModel[Never]()v.model_dump()# TypeError: type `never` cannot be serialized

On the other hand, serialising models containing never fields should work and the never fields should be omitted:

classModel(BaseModel):a:NeverassertModel().model_dump()== {}

These are covered by the new test cases included in this PR.

Manual integration test

Tested locally with the counterpart implementation for pydantic and it worked.

Related issue number

Part ofpydantic/pydantic#9731

Checklist

  • Unit tests for the changes exist
  • Documentation reflects the changes where applicable
  • Pydantic tests pass with thispydantic-core (except for expected changes)
  • My PR is ready to review,please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer:@sydney-runkle

@codspeed-hqCodSpeed HQ
Copy link

codspeed-hqbot commentedDec 10, 2024
edited
Loading

CodSpeed Performance Report

Merging#1579 willnot alter performance

Comparingchanghc:9731-never (3b439fa) withmain (52e9a53)

Summary

✅ 157 untouched benchmarks

@codecovCodecov
Copy link

codecovbot commentedDec 10, 2024
edited
Loading

Codecov Report

Attention: Patch coverage is7.59494% with73 lines in your changes missing coverage. Please review.

Files with missing linesPatch %Lines
src/validators/never.rs0.00%33 Missing⚠️
src/serializers/type_serializers/never.rs0.00%32 Missing⚠️
src/serializers/type_serializers/model.rs0.00%5 Missing⚠️
src/errors/types.rs0.00%2 Missing⚠️
src/serializers/shared.rs0.00%1 Missing⚠️

📢 Thoughts on this report?Let us know!

@changhcchanghc marked this pull request as ready for reviewDecember 11, 2024 22:51
@changhc
Copy link
ContributorAuthor

please review

pydantic-hooky[bot] reacted with thumbs up emoji

@davidhewitt
Copy link
Contributor

@pydantic/oss would love your input on this design. I would have assumed a simpler design where any type containing aNever field (be itRootModel,BaseModel etc) would itself not be instantiable, becauseNever is not. Maybe there is some context I am missing.

marvinth01 reacted with thumbs up emoji

@MarcBresson
Copy link

any traction on that PR? I'd love to have Never supported in pydantic :)

@samuelcolvin
Copy link
Member

Thanks so much for contributing, but I don't really see why this needs to be in core?

@Viicos
Copy link
Member

I think we can have a simpler alternative in pydantic, that generates aplain validator (and a serializer) unconditionally raising aPydanticCustomError.

Anyway, I'm also interested in knowing the use cases for this: why do you need a field to always fail when validating?

marvinth01 reacted with thumbs up emoji

@marvinth01
Copy link

I agree that the validator and serializer should unconditionally raise an exception.
If you ever want to instantiate something with a never field what you're trying to do is unsound, and if you're at a point where you could serialize it, something has gone horribly wrong at an earlier point in time.

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

@sydney-runklesydney-runkle

Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

7 participants
@changhc@davidhewitt@MarcBresson@samuelcolvin@Viicos@marvinth01@sydney-runkle

[8]ページ先頭

©2009-2025 Movatter.jp