> > One thought: No. > I was still typing out my last reply when you wrote this Guido. With that I think I will officially retract the entire suggestion.
Though I'm disappointed because casing-consistency is one of those things I care about far more than I probably should (I couldn't explain the why, I just do), I respect your opinion massively as I'm sure most of our community does, so I don't see any benefit in continuing the discussion if you're soundly against it. Thanks to everyone who chimed in with their opinions, have a good rest of your day :) On Thu, Nov 11, 2021 at 7:53 PM Guido van Rossum <gu...@python.org> wrote: > One thought: No. > > On Thu, Nov 11, 2021 at 05:41 Matt del Valle <matthew...@gmail.com> wrote: > >> So I was reading the docs for the `threading` module and I stumbled upon >> this little note: >> >> Note: >> >> In the Python 2.x series, this module contained camelCase names for some >> methods and functions. These are deprecated as of Python 3.10, but they are >> still supported for compatibility with Python 2.5 and lower. >> >> >> And it got me thinking. >> >> Given that there is some precedent, would it be feasible to make a >> concerted effort to add aliases across the board for all public-facing >> stdlib types and functions that don't follow pep8-recommended casing? >> >> I realize that large chunks of the stdlib predates pep8 and therefore use >> various non-uniform conventions. For example, the logging module is fully >> camelCased, and many core types like `str` and `list` don't use PascalCase >> as pep8 recommends. The `collections` module is a veritable mosaic of >> casing conventions, with some types like `deque` and `namedtuple` being >> fully lowercased while others like `Counter` and `ChainMap` are PascalCased. >> >> >> My motivation for this twofold: >> >> 1) I'll confess that this has just always been a wart that has bothered >> me way more than it has any right to. I just *hate* it. Somewhere deep >> inside my lizard-brain it makes me unhappy to have disparate naming >> conventions in my code. I realize this isn't a good reason in and of itself >> but I wonder if this might not be the case for others as well. While I've >> come to accept it because that's just how it is, maybe it doesn't have to >> be this way? >> >> 2) It's always been an extra thing to explain when teaching python to >> someone. I always try to cover pep8 very early to discourage people I'm >> training from internalizing bad habits, and it means you have to explain >> that the very standard library itself contains style violations that would >> get flagged in most modern code reviews, and that they just have to keep in >> mind that despite the fact that the core language does it, they should not. >> >> >> So the scope of my suggestion is as follows: >> >> - lowercase types become PascalCase (e.g., `str` -> `Str`, >> `collections.defaultdict` -> `collections.DefaultDict`) >> >> - lowercase attributes/functions/methods become snake_case (no changes >> for names that only contain a single word, so `str.lower()` would be >> unaffected, but `str.removeprefix()` would get the alias >> `str.remove_prefix()`) >> >> - pep8 and the python docs are updated to state that the pep8-compliant >> forms of stdlib names should be strongly preferred over the legacy names, >> and that IDEs and linters should include (configurable?) weak warnings to >> discourage the use of legacy-cased stdlib names >> >> - `help()` would be special-cased for builtin types to no longer display >> any current non-pep8-compliant names, and the python docs would also no >> longer show them, instead only making a note at the top of the page as with >> the `threading` module. >> >> >> Given the horrors of the python 2.7 schism I don't think there's any rush >> to officially deprecate or remove the current non-pep8 names at all. I >> think that's the sort of thing that can happily and fully be kicked down >> the road. >> >> If we add aliases and they see widespread adoption to the point where the >> non-pep8 forms are barely ever even seen out in the wild then maybe in 10 >> or 20 years time when the steering council is deliberating on a new major >> python version they can consider rolling the removal of legacy badly-cased >> names into it. And if not then no big deal. >> >> So yeah, thoughts? >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UISOU3G4S75RNP37LNINB4ALTC2S5UG7/ Code of Conduct: http://python.org/psf/codeofconduct/
