I mentioned why I think the benefit is not minimal (quantity/prevalance of usage/teaching of logging, ease-of-reading), and you’ve mentioned that you think the benefit is minimal…
…and if the benefits and the burdens are hard to judge…I guess we can just leave it at “Some people are willing to spend time on this” and “Some people are not willing to spend time on this” until some core developer gets convinced such a PEP is worth sponsoring.
Thanks Jelle. Hopefully we can find a sponsor for some suitable variation of this proposal.
Hah – well, that should be fixed. Where do you see the violation?
(I wanted to reply to this separately to not bother Jelle / direct the reply at you primarily, but discuss won’t let me post more than twice :/)
Whatever benefit there is, you won’t see it until you don’t have to support any version older than X.Y (the one where the aliases came in). Personally, I think the benefit is marginal at best, but you might consider that the benefit is greater. In any case, it’s quite irrelevant what you or I think, and it only really matters whether a core dev believes it’s worth doing.
Which means… even if you DO add aliases, you still have some inconsistency. Awesome. (Don’t know what your “very hard” is potholed to; the site is spinning without loading.)
That phenomenon ALSO magnifies the costs, though. There are all manner of recipes, examples, tutorials out there, and they’re all going to be using the existing names. When some of them start using different names, that causes confusion. If the docs recommend one thing but every tutorial you read recommends another, that causes confusion. Etcetera.
If there IS a way to minimize the cost, someone will need to figure out what that way is. The mere fact that it might exist isn’t sufficient. And given how hard it is to quantify those costs, it’s most likely going to need to be someone who would actually shoulder a lot of that burden who figures that out - ie a core dev.
My list:
.format-style templatingI’m pretty sure 95% of people who want PEP8 consistency never actually read the PEP. None of them seem to remember the second section of the document. Not that cannot disagree with it, but they always seem surprised when it’s brought up.
This is very likely a consequence of linters complaining about “PEP 8 compliance”. Though fortunately, some of those have since been reworded.
Are you referring to the point you made in:
The rest of this thread is about people advancing the argument about why that reason you quoted does not apply: specifically, that there is indeed “[another] reason to be modifying that code”. I thought @elis.byberi was saying something novel and specific and able-to-be-discussed, rather than just “the whole proposal is defeated by reason #3 because I think it is”.
I personally would have found the Naming Conventions paragraph saying “where an existing library has a different style, internal consistency is preferred” to be a much better counter-argument to this proposal.
Why the ad hominen? Why do you say we haven’t read the PEP? If you mean other people not involved in this discussion, why bring it up? I understand the argument “there is no need for PEP-8-related changes because PEP-8-ignore-reason-#3 applies”; the point of this proposal is to argue that PEP-8-related changes to logging are indeed worthwhile and don’t fall under that exception.
If someone makes a concrete proposal that minimises the cost in the way you suggest, that would be a very different discussion. But nobody has made such a proposal.
To give a specific cost that’s close to my heart, and which I feel is very often ignored - if these aliases were added, existing projects that use the logging module would see people raising issues and/or PRs requesting that the project use the “new names”. Whether the project makes the change or not, there’s a significant cost triaging such requests, reviewing PRs, and possibly fixing bugs introduced by the renaming (nothing is ever as simple as people hope it will be). It’s very easy for someone to post an issue or a low-cost search-and-replace PR, just to get “internet points” or to be able to put “contributed to XXX” on a resumé.
Personally, I think you’re unlikely to get a sponsor unless you demonstrate a better understanding of the costs, and how you’ll mitigate them. Explaining the benefits of a proposal is generally pretty easy. The proposals that stand out are the ones that don’t shrink from acknowledging (and addressing) their costs head-on.
Thanks. I’m not the original proposer, so I wasn’t trying to convince everyone I understand the costs. As nobody in this discussion has professed to understand the costs…I guess I’m in good company.
I get it, completely. Shame it seems we’re stuck with some Java names in Python and too much inertia to change it now.
I’m pretty sure 95% of people who want PEP8 consistency never actually read the PEP. None of them seem to remember the second section of the document .
You mean the one that contains the following paragraph?
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.
It’s no different from other oddities like that, by convention, classes have uppercase first letters… but a lot of core Python type names don’t. It’s history. There’s no reason to change int to Int or defaultdict to DefaultDict just to match a convention. (Though that particular argument is muddied somewhat by typing, where those uppercased names ARE used.)
I explained why I said that in the rest of the message. If you actually read the text, count yourself in the other 5%.
The PEP says
Some other good reasons to ignore a particular guideline:
[…]
3. Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.
Like to me that reads as: “Unless you have a really good reason (and no consistency in and of itself is not a really good reason) you shouldn’t force adoption of PEP8 in the stdlib”.
You may disagree, that’s fine, but few “PEP-8 enthusiasts” (for lack of a better term) remembers this very important section of the document and is why more than one person in this (and all the other threads) say that forcing PEP 8 compliance for the sake of consistency is itself not PEP-8 compliant.
Anyway I said what I felt I have to say, wish you luck with your endevours regarding this!
(Emphasis mine)
Yup, that one.
I understand this argument and am not advancing it.
When people say “PEP 8” they generally just mean the style that’s described there. Not every programming language has a style guide written by the original creator of the language, which then became the default for the entire community even if it was only originally intended for the standard library. That’s a rare gift - but that doesn’t prevent me from actively disagreeing with parts of what’s written in the PEP.
Most users probably haven’t even looked at standard library code to see how well it conforms to the standards described - except, of course, the names documented in the public API. And they certainly don’t refer each other to PEP 8 for philosophy about how to write code or what their priorities should be. They do it so that programmers within their organization can be on the same page, and to build an ecosystem where friction is automatically minimized when people submit their first PR to some open-source Python project.
PEP 8 is seen as a style guide because people want a style guide and they weren’t told not to use it that way. Schelling points are important.
Cognitive load is a cost. Using names that match a programmer’s default expectation, now that such an expectation has been set, is a clear benefit, contrary to prior objections. Not everyone uses an IDE (I actively hate every one I’ve tried - yes, including IDLE - and find that their best use is in generating the exact kind of boilerplate that Python doesn’t make me write), so being able to remember a name and its spelling avoids breaking my flow. Even with an IDE, having to select a name from a drop-down list that “looks wrong”, is jarring.
Edit:
To be clear, the point here is absolutely not to “force adoption of PEP8 in the stdlib” - i.e., to try and hold the core devs to their own principles or whatever. That’s why the OP is proposing to add aliases for PEP-8 compliant names - i.e., the part that is relevant to the public API. It’s not about fixing indentation or bracketing or internal-spacing style in 30-year-old (gosh, it really could theoretically be that old in some cases, couldn’t it?) code. And the reason for this is to enable consistency in the user’s code.
Aside from the actually difficult cases like lastResort, though, I have to concede that this can be accomplished by e.g. monkey-patching some method names in a wrapper in the user’s codebase…
I was suggesting that we should adhere to the entire PEP-8 style guide. For example, when porting a library from another language, maintaining the same API naming is recommended.
I still don’t understand why you think I disagree with your quoted interpretation. I think you think I’m saying the logging module should be change to be consistent just because I like things consistent. I’m not. I’m saying that the poster identified an opportunity to improve logging for a sake other than just ‘a foolish consistecy’ which seems like a good idea and I am willing to help. I appreciate your perspective that change for change’s sake is not worthwhile, and I totally agree with that.
Fair enough! I especially think this makes sense when more people knew the log4j API than probably do now.