Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

Hmm, looks like None should raise a TypeError and not a ValueError. That was unexpected.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Barneygale, I have made the requested changes; please review again.

Thanks for making the requested changes!

@barneygale: please review the changes made to this pull request.

Eh, there seems to be a bug with @bedevere-app:

• I converted this issue to a draft & back
• bedevere-app added "awaiting review" & removed "awaiting change review".

Not entirely sure where to report that...

Don't worry about making commonpath() a little slower if you're fixing a bug, that's no problem. You don't need to compensate for it by speeding up other methods! Those speed-ups look nice, but I think they might be easier to review in their own PR, if that's no trouble? Thanks!

I was simply refactoring the other functions to make them more readable, while waiting for suggestions.
But, must I put the bug fixes for ntpath.commonpath & posixpath.realpath (coming up) in separate pull requests?

Yes please, separate PRs for separate changes makes each one easier to review.

Note that we don't accept changes that only improve readability. It causes too much churn and too many arguments. But you're welcome to improve readability as part of another change, e.g. a bugfix, enhancement or speed-up, as long as you're not introducing too much risk by tinkering with delicate code. Hope that makes sense?