gh-104683: Argument clinic: cleanup DLSParser state_foo methods
#107543
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.
The
DSLParserclass has a lot ofstate_foomethods. All of these have to have the same type annotations, because none of them are actually called directly -- they're all called indirectly via thenext()method:cpython/Tools/clinic/clinic.py
Lines 4644 to 4652 in 6ef8f8c
cpython/Tools/clinic/clinic.py
Line 4670 in 6ef8f8c
cpython/Tools/clinic/clinic.py
Line 4731 in 6ef8f8c
(etc. etc.)
All of these are only ever passed a
strfor theirlineparameter, and assume that they're only ever passed astrfor theirlineparameter. All, that is -- except one! Thestate_terminalmethod is explicitly passedNonein the one place that it's called, and will indeed error if it's passed anything that's notNoneor"":cpython/Tools/clinic/clinic.py
Lines 4614 to 4615 in 6ef8f8c
cpython/Tools/clinic/clinic.py
Lines 5576 to 5580 in 6ef8f8c
As a result of
state_terminal, all of ourstate_foomethods have to havestr | Noneannotations forline, which means we need to have many pointless assertions everywhere to keep mypy happy. But sincestate_terminalis special (it's the only one of thestate_foomethods that expects to be passedNone, and it's only ever called once, after the entire block has been parsed), we can just... special-case it. If we rename it todo_post_block_processing_cleanup(), and call it explicitly after parsing the block rather than indirectly vianext(), this allows us to greatly simplify the typing across the rest of theDSLParserstate_foomethods, and makes the code generally much more readable for humans as well.Tools/clinic/#104683