I think this is low priority, but do core developers have a plan to make code in standard library more PEP8-compliant?
I feel ashamed when introducing Python to non-Python programmer and he/she see a lot of red error indicator in VS Code when accidentally open std lib source code.
No, we don’t have any plans on changing the stdlib to match PEP 8. As PEP 8 itself says, don’t break backward compatibility to comply with it. That leaves out public name changes. And we don’t accept changes for internal reformatting: it’s not worth the risk of breaking existing code, and it breaks pending PRs.
Additionally, reformatting existing code just for PEP 8 compliance takes up the already very limited (and almost entirely voluntary) resources for PR review that could be much better used for bug fixes and new features. Doing so would provide minimal practical benefit at a significant cost.
PEP 8 has a good use as a styling guide for incoming patches, but it’s most certainly not worthwhile to make the entire stdlib compliant.
You also lose accurate git blame information for lines of code
This is actually not strictly true anymore. git supports ignoring certain commits in the blame: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
However this does require a manual git config command and I’m not sure if GitHub supports it yet. There’s prior art too with both llvm and v8 using it:
Huh, that’s cool. So that means the only thing stopping someone from running black over the entire standard library is compatibility with (the over 1000) existing pull-requests
Maybe you can treat it as a teaching opportunity to introduce some core Python values? Like “Readability counts” (isn’t it great that we have good code formatting guidelines and editors that help us implement them?), “Learn by doing” (our understanding and tools for making readable code have evolved a lot over the past 30 years), and “Practicality beats purity” (readability is important, but we shouldn’t be dogmatic about it, and should weigh it against other things like the risk of disruption from modifying old well-tested code).
[Laurie O]
“So that means the only thing stopping someone from running black over
the entire standard library is compatibility with (the over 1000)
existing pull-requests”
Well, there’s also PEP 8.
I’ve heard the arguments against cleanup before.
I’d like to hear arguments for cleanup.
Let me propose one small argument for cleanup in general (not strictly PEP8).
As language develops, stdlib ought to get updated with new features, e.g. context managers, walrus operator. I’m sure there’s precedent in exception raising and handling.
Perhaps one day, in similar vein, public API could get aliases or could be renamed with backwards-compatible aliases added. That obv. needs a process, something like PEP-for-stdlib improvements.
Here’s another use of blame ignore that I worked on, with scripts to configure your local repo:
I have also submitted an issue request to GitLab and a developer support request to GitHub that references the GitLab issue.
If CPython starts using it, maybe GitHub would be more likely to support it!
Please upvote/comment on this issue for GitLab and tell GitHub you want this.
I’m completely opposed to this. Aliases add a burden forever. The original name can never go away. Consider the case of old pickle files that reference the old name.
Many areas of the stdlib have been updated to use context managers where they provide a practical benefit, such as for file IO. It can help in dealing with various resource-related errors when cleanup is a concern. @storchaka recently merged such a change in bpo-39916: Use os.scandir() as context manager in Path.glob(). by serhiy-storchaka · Pull Request #18880 · python/cpython · GitHub.
But there should be some practical benefit gained for changing the existing code, IMO. If it’s a very minor readability enhancement, it’s not worth the review or maintenance resources.
I think there are a few exceptional cases in which backwards-compatible, deprecated aliases are appropriate, such as the ones for unittest. So, I’m not completely opposed to them in all situations.
But we should definitely not go out of our way in actively seeking new aliases; instead, they should require an adequately strong argument/use case to justify the substantial long-term costs.
No, we don’t have any plans on changing the stdlib to match PEP 8. As PEP 8 itself says, don’t break backward compatibility to comply with it.
This means that that code is untouchable forever?
If some code is being touched for other reasons (adding features, fixing a bug), then we might accept some reflowing, renaming of local variables and private methods, etc., as long as they actually improve the code. We can’t change publicly visible details, like visible function, method, and parameter names.
And we don’t want to accept general “cleanup” PRs because they’re hard to validate and might introduce breakages, just for the sake of looking better.
In the large, I’d say the answer to your question is that the stdlib is largely going to remain untouchable for code cleanups.