-
Notifications
You must be signed in to change notification settings - Fork 285
[conformance suite] Update an assertion in historical_positional.py to allow an optional error
#2167
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
base: main
Are you sure you want to change the base?
Conversation
… to allow an optional error The comment immediately above the `f3` definition states: ```py # > Consistent with PEP 570 syntax, positional-only parameters cannot appear # > after parameters that accept keyword arguments. Type checkers should # > enforce this requirement: ``` But mandating that type checkers should permit the `f3` definition appears inconsistent with this comment. The `x` parameter of this function accepts keyword arguments, and comes before a parameter that uses the legacy convention for denoting positional-only parameters, so according to the portion of the spec quoted here I think type checkers *should* emit an error on it. This PR updates the line to allow an optional error to be emitted by type checkers (though I'd personally also be okay with mandating an error).
historical_positional.py…historical_positional.py to allow an optional error
|
|
||
|
|
||
| def f3(x: int, *args: int, __y: int) -> None: ... # OK | ||
| def f3(x: int, *args: int, __y: int) -> None: ... # E? |
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 mandating that type checkers should permit the f3 definition appears inconsistent with this comment. The x parameter of this function accepts keyword arguments, and comes before a parameter that uses the legacy convention for denoting positional-only parameters, so according to the portion of the spec quoted here I think type checkers should emit an error on it.
Can you call f3 with x as a keyword argument though? Won't you get SyntaxError: positional argument follows keyword argument? So is it maybe the case that you can't actually use x as keyword argument based on that constraint from it's positioning before positional arguments.
# > Consistent with PEP 570 syntax, positional-only parameters cannot appear
# > after parameters that accept keyword arguments. Type checkers should
# > enforce this requirement:
So this then does apply?
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.
You can call f3 with x as a keyword argument; you just can't do it while also providing any additional *args:
>>> def f3(x: int, *args: int, __y: int) -> None: ...
>>> f3(x=1, __y=2)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.
I should probably add a comment above the definition of f3 clarifying this, since it's admittedly a little subtle
carljm
left a comment
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.
I think type checkers should be allowed to reject this definition.
The comment immediately above the
f3definition states:But mandating that type checkers should permit the
f3definition appears inconsistent with this comment. Thexparameter of this function accepts keyword arguments, and comes before a parameter that uses the legacy convention for denoting positional-only parameters, so according to the portion of the spec quoted here I think type checkers should emit an error on it.This PR updates the line to allow an optional error to be emitted by type checkers (though I'd personally also be okay with mandating an error).