[conformance suite] Update an assertion in historical_positional.py to allow an optional error#2167
[conformance suite] Update an assertion in historical_positional.py to allow an optional error#2167AlexWaygood wants to merge 1 commit intomainfrom
historical_positional.py to allow an optional error#2167Conversation
… 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).
AlexWaygood
changed the title
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.
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.
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.
I should probably add a comment above the definition of f3 clarifying this, since it's admittedly a little subtle
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
I think type checkers should be allowed to reject this definition.
5 participants
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).