Skip to content
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

gh-104683: Argument clinic: cleanup state_modulename_name() #107340

Merged
merged 3 commits into from Jul 27, 2023

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented Jul 27, 2023

The state_modulename_name() function has two variables named module, that have different purposes and that are assigned to objects of different types:

module, cls = self.clinic._module_and_class(fields)

cpython/Tools/clinic/clinic.py

Lines 4746 to 4750 in 6e850c3

module = None
try:
module = ast.parse(ast_input)
except SyntaxError:
pass

If we give the second variable a different name, it makes the code easier to understand for mypy and for humans. I also made some incidental changes to nearby lines to use f-strings rather than string concatenation using +.

(This PR is required in order to add type hints to the last remaining untyped function in clinic.py, _module_and_class().)

@erlend-aasland
Copy link
Contributor

This is a very nice improvement, indeed. A lot of the error paths in this PR don't have test coverage, yet. IMO, we should bring test coverage of state_modulename_name() up to 100% before continuing with this PR. I can give that a stab tonight, unless someone beats me to it :)

@erlend-aasland
Copy link
Contributor

Thanks!

@AlexWaygood AlexWaygood merged commit c2b1689 into python:main Jul 27, 2023
23 checks passed
@AlexWaygood AlexWaygood deleted the clinic-modulename-name branch July 27, 2023 21:51
@erlend-aasland
Copy link
Contributor

(Sorry, I forgot to mention: we should add tests in separate PRs, since we normally want those backported to bugfix branches.)

@AlexWaygood
Copy link
Member Author

AlexWaygood commented Jul 27, 2023

(Sorry, I forgot to mention: we should add tests in separate PRs, since we normally want those backported to bugfix branches.)

In general, I agree -- but here, adding tests revealed some micro-bugs in the failure messages, so I would have had to assert arguably incorrect behaviour in the tests in order to backport them to bugfix branches. Unless we consider the microbugs in the failure messages important enough to warrant backporting this PR as a bugfix, which I personally don't? Anyway, that was my thought process :)

@bedevere-bot

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants