Correctly parse and cross-reference unpacked type annotations #13369
Conversation
agraboso
force-pushed
the
pep646-args
branch
from
8d0b968 to
e326ad6
Compare
|
Given that this is the first PR after the release of v8.2.0, I'm not sure how to record it in |
I've now updated CHANGES for the 8.3 header. Sorry for the trouble. A |
agraboso
force-pushed
the
pep646-args
branch
2 times, most recently
from
0959703 to
20e8d33
Compare
|
Entry added to CHANGES. |
agraboso
force-pushed
the
pep646-args
branch
3 times, most recently
from
a9b2a27 to
0a874c2
Compare
| @@ -508,6 +508,28 @@ def test_parse_annotation(app): | |||
| ), | |||
| ) | |||
|
|
|||
| doctree = _parse_annotation('*tuple[str, int]', app.env) | |||
There was a problem hiding this comment.
Is *tuple[...] a valid stand-alone type annotation? If not, should we have some validation that Starred only comes after [?
I'm happy to keep things as currently proposed in this PR, just unsure which is the best approach.
There was a problem hiding this comment.
It is valid in the context of variadic generics annotations (see https://peps.python.org/pep-0646/#unpacking-tuple-types). In other places it is not, but I worked this out under the assumption that Sphinx is looking to accept all valid Python behaviors, not disallow non-valid ones (that would be neat, but would probably imply reimplementing a huge part of the parser in any Python implementation).
With respect to what you are saying about validating it only comes after [: I came out with this PR to deal with annotations in type signatures in function arguments, not in type parameter specifications alla PEP 695. I am AFK and I don't remember off the top of my head if it does come into parsing the latter. I will look into it as soon as I can.
Closes #13368