The cost of having two ways to name things for the indefinite future is
too high. Not only would you have to maintain it in the various Python
implementations, you'd have to explain why code uses "str" or "Str", or
both.
The costs of migration are also too high. I personally work on a 20 year
old proprietary python code base that would never be updated for a
change like this. Unless you plan on breaking it in another 20 years
(and I do expect it to still be running then), the old names can never
go away.
Maybe if there was an automated tool, the migration to the new names
would be possible. You'd need a tool that's smarter than 2to3 in order
to update code like: "str = 'foo'". But even if a perfect tool existed,
it would take man-months and many tens of thousands of dollars to test
such a large code base. My clients are understandably unwilling to do
that for no functional gain.
So, like many things in Python[0], the various naming conventions across
modules and time is just something we're going to have to live with.
Eric
[0]: One tiny example of many: I wish I hadn't added dataclasses.asdict
and .astuple, but now I've got to live with it.
On 11/11/2021 8:41 AM, Matt del Valle 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 topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/
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/LEDWRRN7IEE323XRAZTP6TDCZKMXDBUN/
Code of Conduct: http://python.org/psf/codeofconduct/
