As I was working on removing Python 2 references from PEP 8 (PR: https://github.com/python/peps/pull/2059), I tried to avoid any other copy-editing. However, I noted a few things that maybe could use some attention: stdlib or not? ########## Right at the top, it says: "This document gives coding conventions for the Python code comprising the standard library in the main Python distribution." However, it has become a de facto standard for all Python code, and in the document itself, there is frequent wording akin to "Identifiers used in the standard library must be ASCII compatible ...", and even advice for third party libraries. Which I think is acknowledging that PEP 8 is indeed not only about the standard library. So maybe there should be a bit of text about that at the top. Name Mangling ############# In the sections on "Method Names and Instance Variables" and "Designing for Inheritance", the discussion of name mangling (leading __ names) is a bit redundant. Nothing incorrect or misleading -- just a copy-editing issue. Maybe I'll do a copy-editing PR .... -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
This was my thought as I read the original thread yesterday. There are tools in the wild which base their style recommendations/enforcements on PEP 8. Heck, there is even a tool in PyPI called "pep8." While 2.x is out of support, it *is* still used by many organizations. If nothing else, it would seem to be useful to branch the pep8 repo ("lastpy2" perhaps?) just before applying Chris's updates. That would allow enterprising folks to easily fork and reference back to the last point where the PEP 8 text did mention Python 2.x. (This no longer applies to me personally, as I have fully gone over to Python 3, but at my last job there was still plenty of Python 2 code to be had.) Just a thought... Skip
On Fri, Aug 27, 2021 at 3:02 AM Skip Montanaro <skip.montanaro@gmail.com> wrote:
The tool isn't part of this change. Third-party tools which happen to follow PEP 8 to some greater or lesser degree are going to have to make their own choices about what happens. The document itself is free to change. ChrisA
On Wed, Aug 25, 2021 at 10:38 PM Christopher Barker <pythonchb@gmail.com> wrote:
I wouldn't be opposed to that personally. I think a lot of people just think PEP 8 is a doc for the community when it is actually for Python itself and it happens to be very convenient for others to use. Although we obviously understand that people do use it in situations outside of the stdlib, so I don't think saying, "if you're going to use this in a way we didn't mean it to, here's some advice". -Brett
On Aug 26, 2021, at 12:05, Brett Cannon <brett@python.org> wrote:
I wouldn't be opposed to that personally. I think a lot of people just think PEP 8 is a doc for the community when it is actually for Python itself and it happens to be very convenient for others to use. Although we obviously understand that people do use it in situations outside of the stdlib, so I don't think saying, "if you're going to use this in a way we didn't mean it to, here's some advice”.
It might be helpful to acknowledge that PEP 8 *in practice* often serves as the base style guide for code outside the stdlib. IME it rarely serves as *the* style guide though, since there usually are explicit deviations to adhere to organization or personal taste. I’ve also found some tools that maybe take PEP 8 a little too far, like it’s the law, or have different interpretations of the PEP 8 recommendations. The other thing to keep in mind is that, at least historically, we’ve rejected changes to PEP 8 to keep some deliberate ambiguity in the recommendations. PEP 8 can’t and shouldn’t be so detailed as to not give Python programmers some leeway to determine what’s right for them, their teams, or their projects. Cheers, -Barry
This was my thought as I read the original thread yesterday. There are tools in the wild which base their style recommendations/enforcements on PEP 8. Heck, there is even a tool in PyPI called "pep8." While 2.x is out of support, it *is* still used by many organizations. If nothing else, it would seem to be useful to branch the pep8 repo ("lastpy2" perhaps?) just before applying Chris's updates. That would allow enterprising folks to easily fork and reference back to the last point where the PEP 8 text did mention Python 2.x. (This no longer applies to me personally, as I have fully gone over to Python 3, but at my last job there was still plenty of Python 2 code to be had.) Just a thought... Skip
On Fri, Aug 27, 2021 at 3:02 AM Skip Montanaro <skip.montanaro@gmail.com> wrote:
The tool isn't part of this change. Third-party tools which happen to follow PEP 8 to some greater or lesser degree are going to have to make their own choices about what happens. The document itself is free to change. ChrisA
On Wed, Aug 25, 2021 at 10:38 PM Christopher Barker <pythonchb@gmail.com> wrote:
I wouldn't be opposed to that personally. I think a lot of people just think PEP 8 is a doc for the community when it is actually for Python itself and it happens to be very convenient for others to use. Although we obviously understand that people do use it in situations outside of the stdlib, so I don't think saying, "if you're going to use this in a way we didn't mean it to, here's some advice". -Brett
On Aug 26, 2021, at 12:05, Brett Cannon <brett@python.org> wrote:
I wouldn't be opposed to that personally. I think a lot of people just think PEP 8 is a doc for the community when it is actually for Python itself and it happens to be very convenient for others to use. Although we obviously understand that people do use it in situations outside of the stdlib, so I don't think saying, "if you're going to use this in a way we didn't mean it to, here's some advice”.
It might be helpful to acknowledge that PEP 8 *in practice* often serves as the base style guide for code outside the stdlib. IME it rarely serves as *the* style guide though, since there usually are explicit deviations to adhere to organization or personal taste. I’ve also found some tools that maybe take PEP 8 a little too far, like it’s the law, or have different interpretations of the PEP 8 recommendations. The other thing to keep in mind is that, at least historically, we’ve rejected changes to PEP 8 to keep some deliberate ambiguity in the recommendations. PEP 8 can’t and shouldn’t be so detailed as to not give Python programmers some leeway to determine what’s right for them, their teams, or their projects. Cheers, -Barry
participants (5)
-
Barry Warsaw -
Brett Cannon -
Chris Angelico -
Christopher Barker -
Skip Montanaro