No need to inherit from object. I'm writing the patch now.

This code is valid in Python 3. We usually do not accept such pure cosmetic changes.

"We usually do not accept such pure cosmetic changes." Is this an axiom or is the reasoning written down somewhere? I'd think we all like to remove cruft that's no longer necessary.

Similar cleanup (and many many others) was proposed when pathlib was initially added to the stdlib. They were rejected, so now we need a new discussion to revise the old decision. See issue20002.

> Is this an axiom or is the reasoning written down somewhere?

It should be written down in the devguide at devguide.python.org.

I agree with Serhiy that this isn't really adding anything by making the code that much more readable, idiomatic, or faster to warrant the overhead of this issue or the PR.

While I appreciate the effort, Ram, I'm closing this issue as rejected and the related PR.

Brett: Oh well, I understand. Looking at the devguide, I can't find where this is written. I'm interested in seeing how it's phrased, because I do think that tiny, incremental changes are important. I would want to know why, for example, my change https://github.com/python/cpython/pull/17929 was accepted and this one wasn't. Or maybe there isn't a clear cut rule, and it's somewhat random?

If you can't find the guidance then please either open an issue or submit a PR to update the devguide with the info.

As for why your other PR was accepted, that was fixing an actual bug in the docstring. This one has absolutely no semantic change to Python; it's the equivalent of changing some whitespace just because it isn't quite in line with PEP 8. It simply isn't worth the overhead of the PR review or the churn on the file as now the `git blame` info is off for who last made a semantic change to that line.