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/M2H6J7ABPKJNQGJBEDI4M5PLMRJ6EHXY/ Code of Conduct: http://python.org/psf/codeofconduct/
