8000 Recursively unpack `Literal` values if using PEP 695 type aliases by Viicos · Pull Request #11114 · pydantic/pydantic · GitHub
[go: up one dir, main page]

Skip to content

Recursively unpack Literal values if using PEP 695 type aliases #11114

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 16, 2024

Conversation

Viicos
Copy link
Member
@Viicos Viicos commented Dec 14, 2024

Change Summary

Fixes #9269.

Related issue number

Checklist

  • The pull request title is a good summary of the changes - it will be used in the changelog
  • Unit tests for the changes exist
  • Tests pass on CI
  • Documentation reflects the changes where applicable
  • My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

@github-actions github-actions bot added the relnotes-fix Used for bugfixes. label Dec 14, 2024
Copy link
cloudflare-workers-and-pages bot commented Dec 14, 2024

Deploying pydantic-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: fde4552
Status: ✅  Deploy successful!
Preview URL: https://76e0a2d4.pydantic-docs.pages.dev
Branch Preview URL: https://literal-type-aliases.pydantic-docs.pages.dev

View logs

Copy link
codspeed-hq bot commented Dec 14, 2024

CodSpeed Performance Report

Merging #11114 will not alter performance

Comparing literal-type-aliases (fde4552) with main (17b1038)

Summary

✅ 46 untouched benchmarks

Copy link
Contributor

Coverage report

Click to see where and how coverage changed

FileStatementsMissingCoverageCoverage
(new stmts)
Lines missing
  pydantic/_internal
  _typing_extra.py
Project Total  

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

Copy link
Contributor
@sydney-runkle sydney-runkle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, thanks!!

# Note: we could also check for generic aliases with a type alias as an origin.
# However, it is very unlikely that this happens as type variables can't appear in
# `Literal` forms, so the only valid (but unnecessary) use case would be something like:
# `type Test[T] = Literal['a']` (and then use `Test[int]`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to use a str literal here?

Copy link
Member Author
@Viicos Viicos Dec 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if you do:

type Test[T] = Literal['whatever']
MyLit = Literal[Test[int]]

MyLit.__args__[0] is a GenericAlias instance, and here we only check for is_type_alias_type. But as I mentioned in the comment it is very unlikely to encounter such use cases, as it is not necessary (the type variable is useless here as you can't do something like type Test[T] = Literal[T]).

@Viicos Viicos force-pushed the literal-type-aliases branch from cc3186a to b2f4844 Compare December 16, 2024 16:04
@Viicos Viicos force-pushed the literal-type-aliases branch from b2f4844 to fde4552 Compare December 16, 2024 16:05
@sydney-runkle sydney-runkle merged commit acc5902 into main Dec 16, 2024
54 checks passed
@sydney-runkle sydney-runkle deleted the literal-type-aliases branch December 16, 2024 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes-fix Used for bugfixes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nested Literals together with PEP-695 type statement are failed to produce json schema
2 participants
0