Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

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

Hmm, looks likeNone should raise aTypeError and not aValueError. That was unexpected.

Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip 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 phraseI 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 makingcommonpath() 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 forntpath.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 thatonly 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?