Who’s going to maintain that module? I still haven’t seen any core devs step up. Are you personally willing to do the work? If so, create the module on PyPI, and start promoting something like:
import md_logging as logging
(or any other name - I stuck your initials into it but you could use whatever name you like)
And if you’re not willing to do the work, who are you asking to do it for you?
Expressing support for someone else’s idea should not have to come with a pledge of one’s own time to implement it. In the sentence you quoted, I was asking whether that approach would change anyone’s mind. I was [edit: also] hoping to elicit suggestions (from anyone still following this discussion, that is).
That being said, sure, I can take a stab at it next week if no-one else (including the OP, which I am not) will; I guess I already put my head a bit above the parapet earlier.
That’s true, and I apologize; the “you” was meant in the generic sense. My point is, someone needs to be willing to do the work, and since that doesn’t seem to be someone from the core dev team, it’s going to have to be on PyPI - and who’s it going to be? Who is willing to actually put in the work?
5 posts were split to a new topic: Logging as a tree structure
Yes, and the logging library was committed on Nov 13, 2002, by one of the PEP-8 authors himself, Guido van Rossum.
Note:
We should view the logging library as an application of PEP-8 rather than attempting to fix it.
I don’t want to be pedantic, but I’m eager to follow the discussion about enhancing the logging library (not the PEP-8 thing). Could someone with the necessary permission split this discussion into another topic?
I’m personally not normally a fan of multiple ways to do the same thing (including aliases). If we could do it all over again, sure use PEP8 style, but we are where we are at this point.
If someone wants to make PEP8 aliases, they can publish a package and try to convince people it’s better style, etc. to use it. If it gets big, I could imagine a possible merge into the stdlib. We don’t really have data here other than specific people’s thoughts on the matter.
Honestly this conversation reads a bit hostile at this point. Just a reminder that folks shouldn’t think of
(or make) things as personal. We’re all Python community members here. Maybe this should be locked to allow folks to calm down a bit.
(Unless I’m reading it wrong, at which point sorry).
For fun I played with this a tiny bit. If someone wants pep-8 compatible names, they could use something like this: snakeify_sample.py - Sample code to convert logging to have snake-case aliases. · GitHub
Using that you can do something like:
logging = pep8ify('logging')
# logging has been imported and given snake_aliases.
I wouldn’t recommend using it in production, as I imagine there are plenty of edge cases and weird things, but its interesting to play with.
Edit: I’ve changed the gist from pep8ify to snakeify_sample, etc. I’ll leave the above for original context.
Part of the reason that these debates keep on coming up is that the term “pep8” is used for this sort of tool. In my personal opinion - and I am not a core dev or PSF board member or anything - this sort of naming causes far too many problems, and should not be used. Call it what it is: a snakecasifier. This does NOT make the module comply with PEP 8, and it ignores several very important aspects of the document, pretending that the only thing necessary for compliance is to rename everything.
Please consider a better name for this.
Yep, for precedent, the pep8 style guide checker was renamed to pycodestyle:
Similarly, if this proposed PEP went forward, it should be reframed not around PEP 8-compliancy (as several PEP 8 caveats have been pointed out in this thread) but around snake_casing or something.