I'll simply say that while I am disappointed that there are so many frictions here for whatever reason, I *strongly* appreciate the work done to update threading, I get a deep sense of satisfaction using *correct* naming conventions whenever using this library, and am glad that it got through somehow
On Thu, Nov 11, 2021 at 12:01 PM Matt del Valle <matthew...@gmail.com> wrote: > 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/ >
_______________________________________________ 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/OEKBBZYJ7IFTCMWTP4SD3PDZJQ6CR2OO/ Code of Conduct: http://python.org/psf/codeofconduct/
