I think the disagreement here is that they identified something that makes changes worthwhile. I do not, to me it seems OP just wants consistency for consistencies sake and doesn’t elaborate much. Am I correct in thinking you do think they make a good case for these changes? If so, that’s fine, just a small disagreement in a fairly unimportant topic IMO.
… and this risk is somehow not ever-present? There are any number of trivial refactorings and bikeshedding possible on any given block of code. Since we’re talking about logging here, it hardly seems likely that any of these names would end up as part of the public API of anyone else’s project; PRs can just be blanket rejected, and issues amounting to “I didn’t identify a problem with the project but I don’t like how the code is written” can be dismissed as trolling (for those who are serious about the objection, that’s what forking is for).
2 Likes
Yes, it is, but isn’t it intuitive that there will be more of it if there are these aliases?
This is a very real cost.
1 Like
This is what I disagree with. To me, the consistency you’re after is the hobgoblin the section is all about. But funnily, now that I read some explanations of the quote, my thinking that you shouldn’t change things just to be consistent could itself be considered a hobgoblin of my small mind.
As a sidenote, could you please not edit to answer a completely different post? I did initially like your post because I think everything up until the edit but now I want to remove it (but can’t for some reason, possibly because I liked it before the edit.)
1 Like
Yes, I think there is an arguable case for these changes (I’m not sure the OP has made it :)). I understand if you disagree – as you say, it’s not an earth-shattering topic.
1 Like
Nobody has ever said that consistency is bad. Yes, there would be benefit to having the entire stdlib consistent. However, you won’t just achieve consistency. What you’ll get is duplicated names. There will be the original names and the new names. And that is not a benefit, that is a cost.
The question is not “is there any benefit to this proposal”. The question is “is there net benefit to this proposal”. And that is what people are disputing.
Glad to see we can remain internet-stranger friends 
1 Like
My reading is that great minds intuit which consistency is foolish and which is wise. It’s easy to measure the time spent on a change that seems to be for its own sake. It’s much harder to assess the time saved down the road. Although really for me, it is not so much about time but aggravation; thinking about the code is the bottleneck, not remembering or typing identifier names.
Sorry about the mix-up. I put it in there because I thought my points were related and belonged together, and then the thread ended up moving much faster than I expected. Very surprised if editing a post blocks un-liking it; that seems rather backwards to me (but also a point for the Discourse feedback forum, or actually Discourse’s meta forum itself).
1 Like
In the standard library, yes. But the point is that codebases already using the old names can keep using them if they want, or migrate if their own cost-benefit analysis supports doing so. And new codebases could just use the new names. Any duplication on anyone else’s part is their own doing.
You’re totally right, btw, but it might be a limitation of new users. discuss wouldn’t let me make more than two posts here for a while, and I was forced to edit to respond (Can we increase the 3-consecutive-post limit? - #5 by pradyunsg) :/. It’s awkward.
1 Like
I don’t think the limit is only on new users, but anyway the comment was directed at me and I had different motivations.
I think it might be better in this kind of discussion for everyone to just slow down a bit. Personally I intend to bow out now, at least for the day.
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.
(Emphasis mine)
Yup, that one.
Except that logging prevents me from having consistency within my modules. And what’s worse, inconsistency in one module or inconsistency in millions of modules?
4 Likes
I have to be honest, I don’t care too much about this “problem”. I would not complain if these aliases were added and gladly use them.
What I was trying to say is that, if you read that section in its entirety, I think it clearly says that changing stuff that already works and is stable just to add consistency is not great. May. Even if the changes were made there would still be “inconsistencies in millions of modules.”, because most won’t be updated. One could even make the argument that it’s even worse globally, because in some modules it would be logging.thisCase but in the other it would be logging.this_case. How confusing for someone trying to learn how to use the logging module!
No matter what we do here there will always be inconsistencies, and I don’t find the arguments in this thread convincing to change the status quo. But I’m also not a core dev in charge of the logging module, so 
1 Like
To be clear, I wasn’t seriously proposing an alternative. But it’s much more realistic than the existing proposal, which doesn’t seem to have any chance of happening.
And like I said: a new logging module is a proposal for a package on pypi. Not in the stdlib
That could be dealt with by making the new API for it something other
than an assignment, such as a set_last_resort() function.
1 Like
The style of the logging module is currently internally consistent. A
renaming of it would also be internally consistent. So on that point the
proposal is PEP-8-neutral.
1 Like
But was the logging module really ported from Java? Or is it a thing of
its own that happened to be inspired by a similar module in Java?
I’ve always thought of it as the latter.
I don’t think the current method for “fixing” this is likely to go anywhere. If you wanted to do this in a way that reduced the downsides people have brought up, I’d suggest considering an object in logging logging.pep8 that could be imported instead of logging. Define __getattr__/__setattr__ on it with a name transformation table, and you then have very little to maintain, and it works properly even with logging.lastResort. You’ll also need to contribute a stub definition for this to the typeshed to keep this working for static analysis since this kind of dynamic lookup isn’t understood by those tools.
I don’t particularly care for updating this module for reasons others have already gotten into, but the argument about cognitive overhead is worth at least nudging this in a direction that it has a potential future and people can weigh that.
2 Likes
You’re right, and I don’t think the module implementation (per se) was ported from java.logging; the logging API was what I (and GP?) was implying was (perhaps too-informally) “ported”; but as you say, it was “heavily influenced by (but not an exact translation of) log4j”.
I like it and from logging import pep8 as logging sounds like it would make a good way forward for one side, if it would avoid many/enough of the downsides from the other side. Would it?