> 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.
>
That's fair enough for people learning python as a hobby or in a context
that's a bit more casual than agile. I generally find myself training
junior/graduate people with OOP backgrounds other than Python (Java, C#,
etc.) for my data engineering team and pep8-compliance is quite important,
because they won't even be able to successfully make commits unless they
can pass the flake8 pre-commit hook, let alone get as far as a merge
review. So I'd say that pep8 is quite important from the get-go.
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?
>
I'd argue this is actually a point *in favor* of the proposal rather than
against. In going through your list I actually discovered lots of things I
found extremely surprising (collections.deque is a type as I expected
whereas collections.namedtuple is actually a factory function). If pep8 had
been introduced at the dawn of (python-)time and the stdlib had been
designed with pep8-compliance in mind, there would be no surprise at all on
the day that I think to myself: 'Hmm, I want to subclass namedtuple, let's
try:'
class MyNamedTuple(collections.namedtuple):
...
and discover that it doesn't work.
Are you aware that removeprefix is very new, and that the alternate
> name remove_prefix was rejected?
>
I was aware of that, yes. The rationale was precisely to introduce it as
`str.removeprefix` for consistency with alllowercase (<- which all other
considerations aside can be very unreadable sometimes, that's, I assume,
why pep8 prefers snake_case) which is itself in contravention of python's
official style guide. This is irrelevant in the event that this proposal is
accepted.
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.
>
This is a semantic misunderstanding, I should have been clearer. In my
head, 'officially deprecating' something means saying that it will
*definitely* be removed in the future, and optionally specifying the
precise date at which it will be removed. Since my suggestion doesn't
necessarily involve ever actually removing the current names from the
language (only potentially, if a future steering council decides to as part
of a future proposal), I didn't consider this to be deprecating them,
exactly. Hopefully that's cleared up. Sorry for the confusing wording.
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.
>
This is an argument that can be made for any change ever made to python,
and consequently I think it's an extremely weak argument. Why change
anything if people won't be confident using it for at least 5 years because
of compatibility concerns with current language versions? Well, as it turns
out time passes and eventually that distant 5-year mark is in the past. I
just checked and... wow yeah f-strings were introduced in 2016! Feels like
only yesterday :)
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.
>
I think this is a fair point, but the same can be said of people
accidentally shadowing any number of other builtins (it's probably most
common with builtins like `type` or `max`). Fortunately every linter/IDE
I've used has had warnings for this so it should be something that happens
rarely, if ever.
I'd also say that subclassing list as `List` is probably just bad style
that should be discouraged anyway, because presumably if you're subclassing
list you're doing it to extend it in some way, and you should pick a more
descriptive name like `ChainableList` (if you're implementing a list where
inplace methods return self and allow chaining, for example), rather than
just `List`
I'd argue that a far more common usage pattern is to assign an instance to
the snake_case version of it's class name, for example:
email_service = EmailService(...)
or for the example in question:
list = List()
I think this is an entirely reasonable usage form for a hypothetical future
codebase that disallows legacy-cased names and enforces it with flake8. But
currently this can't be done.
I think what it boils down to for me is this:
If we went to a disconnected alternate universe where python had never been
invented and introduced it today, in 2021, would we introduce it with a
uniform naming convention, or the historical backwards-supporting mishmash
of casing we've ended up with? Since I think the answer is pretty clear,
I'm strongly in favor of making this minimally-invasive change that at
least works towards uniform casing, even if that dizzying utopia is far
beyond the horizon. Our grandchildren might thank us :p
I do concede that some awkward shadowing edge-cases are the strongest
argument against this proposal. I personally don't think they're that
strong of an argument compared to the eventual payoff, but that's just my
subjective opinion.
On Thu, Nov 11, 2021 at 2:11 PM Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Nov 12, 2021 at 12:41 AM Matt del Valle <matthew...@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-hobgoblin-of-little-minds
>
> When a style guide becomes a boat anchor, it's not doing its job.
>
> ChrisA
> _______________________________________________
> 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/GCYM5VYS3DFTMHQE3FKKW4KLSUUKF43B/
> 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/GNDDLTHNB3UN7FRHIAVOKY2DSFOHEGSQ/
Code of Conduct: http://python.org/psf/codeofconduct/
