On Fri, Nov 12, 2021 at 12:41 AM Matt del Valle <matthewgdv@gmail.com> wrote:
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.
ISTM that this indicates that you're putting too much focus on PEP 8 too early. At no time does the document ever state that all Python code ever written must comply with it. New Python programmers should not feel like they're being forced into a naming convention.
So the scope of my suggestion is as follows:
- lowercase types become PascalCase (e.g., `str` -> `Str`, `collections.defaultdict` -> `collections.DefaultDict`)
Pop quiz: Which of these are types and which are functions (or something else)? bool, classmethod, divmod, enumerate, globals, map, property, sorted, super, zip collections.deque, collections.namedtuple Does it even matter? Especially: does it matter enough to force a name change if a function is replaced with a type, or vice versa?
- 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()`)
Are you aware that removeprefix is very new, and that the alternate name remove_prefix was rejected? https://www.python.org/dev/peps/pep-0616/#alternative-method-names
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.
Wait, are you deprecating them or not? I'm confused. Earlier you were saying that you clearly wanted to stop people from using the old names, but now you're saying there's no rush to deprecate them.
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.
That will never happen. It's still possible today to find code written for older 2.x versions, including some quite popular answers on places like Stack Overflow. Suppose that these aliases were added in Python 3.11. Anyone who wants to write code compatible with 3.10 would want to continue using the existing names, and since the existing names would keep on being supported for the foreseeable future, there would be little incentive to change until several versions have passed. At that point, both names might start being used in parallel (we're talking probably 2025 or thereabouts, although it might start sooner if people are also using syntactic features from 3.11+), but it would take a VERY long time for adoption to the level that the older names are "barely ever even seen". Probably never.
So yeah, thoughts?
Absolutely no value in adding aliases for everything, especially things that can be shadowed. It's not hugely common, but suppose that you deliberately shadow the name "list" in your project - now the List alias has become disconnected from it, unless you explicitly shadow that one as well. Conversely, a much more common practice is to actually use the capitalized version as a variant: class List(list): ... This would now be shadowing just one, but not the other, of the built-ins. Confusion would abound. In closing, I'd just like to highlight one very important section of PEP 8: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgo... When a style guide becomes a boat anchor, it's not doing its job. ChrisA