Mark TypeVar/ParamSpec/TypeVarTuple 'name' as positional-only#15805
Closed
adamtheturtle wants to merge 3 commits into
Closed
Mark TypeVar/ParamSpec/TypeVarTuple 'name' as positional-only#15805adamtheturtle wants to merge 3 commits into
adamtheturtle wants to merge 3 commits into
Conversation
These special-form constructors require `name` to be a positional
string literal (PEP 484 / 612 / 646); type checkers reject the keyword
form, e.g. mypy:
error: TypeVar() expects a string literal as first argument [misc]
The stubs advertised `name` as positional-or-keyword, which misleads
tools that consume typeshed as ground truth. No type-checker behaviour
changes (these are special-cased); the runtime objects are C-level with
no introspectable signature on 3.12+, so stubtest is unaffected there.
Refs python#15804
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
On 3.10/3.11 these special forms are pure-Python with introspectable signatures whose `name` is positional-or-keyword at runtime; the stub now marks it positional-only (the type-system contract). stubtest only checks positional-only accuracy on 3.10 (+ TypeVarTuple.__init__ on 3.11), so allowlist exactly those entries on those versions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Contributor
Author
|
CI note: the failing All checks affected by this PR pass: stubtest is green on every OS/version (including 3.10/3.11, where the new positional-only |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements #15804.
TypeVar,ParamSpec, andTypeVarTupledeclarenameas positional-or-keyword, but every type checker (mypy, pyright, ty, pyre) requires it positionally. This is not a per-checker quirk: the typing spec (PEP 484 / 612 / 646) requires the first argument to be a string literal so the checker can bind it to the assigned variable statically, so any conformant checker must rejectname=.... mypy core, no plugins:This marks
namepositional-only on every constructor overload of the three classes so the stub matches that contract. It is a no-op for type checkers (they special-case these and ignore the signature); the point is third-party tools that read typeshed as ground truth and currently suggest the type-checker-breakingname=form.Scope:
NewTypeand thetyping_extensions<3.13 fallback classes are left out (introspectable runtime signatures, so they would need a stubtest-allowlist change); the >=3.13typing_extensionspath re-exports fromtypingand is covered transitively. On 3.10/3.11 these objects are pure-Python and introspectable, so allowlist entries are included for those versions.