[Python-ideas] Verbatim names (allowing keywords as names)

Neil Girdhar mistersheik at gmail.com
Fri May 18 14:54:13 EDT 2018


On Fri, May 18, 2018 at 10:49 AM Steven D'Aprano <steve at pearwood.info>
wrote:

> On Fri, May 18, 2018 at 08:31:36AM -0400, Neil Girdhar wrote:
> [...]
> > > > I don't like multiple ways of doing the same thing.
> > >
> > > Ah, like when people want to use "class" as an identifier, and since
> > > they can't, they write:
> > >
> > >     klass cls Class
> [...]
> > > Remind me again what the "one (obvious) way to do it" is?
> > >
> >
> > In most cases: cls
> >
> > https://www.python.org/dev/peps/pep-0008/#function-and-method-arguments
>
> The immediate next sentence goes on to say:
>
>     If a function argument's name clashes with a reserved keyword,
>     it is generally better to append a single trailing underscore
>     rather than use an abbreviation or spelling corruption. Thus
>     class_ is better than clss. (Perhaps better is to avoid such
>     clashes by using a synonym.)
>
> So PEP 8 already torpedoes your preference for a single way to spell
> words that clash with keywords:
>
> - use a synonym;
>
> - or a trailing underscore
>
> - except for the first argument of class methods, where we
>   use the misspelling (or abbreviation) "cls".
>
> If you object to this proposed verbatim names on the basis of disliking
> multiple ways to spell identifies that clash with keywords, that ship
> sailed long ago. There has always been multiple ways.
>

Right.  I think it's pretty clear that there is one way to avoid naming
conflict and keep the same name: use a trailing underscore except when it's
the first argument to a class method.

>
> But I like to think that verbatim names could become the one OBVIOUS way
> to do it in the future.
>

That's what I don't want.

>
>
> [...]
> > All of your arguments would have applied to a keyword escaping proposal
> had
> > it been proposed before "given" was even considered.
>
> Every new idea has to be thought of for the first time. Otherwise it
> would have been in the language from day zero and it wouldn't be a new
> idea. If it wasn't "given", it could have been for "async" and "await",
> if not for them it could have been for "with", if not for "with" it
> might have been "yield", and so on.
>
> There had to be a first time for any idea. I would have
> suggested this twenty years ago if I thought of it twenty years ago, but
> I didn't, so I didn't. Dismissing the idea because I didn't suggest it
> earlier when other keywords were suggested is illogical.




>
> > The only reason we're
> > even considered considering escaping is to keep code that uses "given" as
> > an identifier working.
>
> That might be the only reason YOU are considing it, but it definitely
> isn't the only reason for me. And probably not for others.
>
> In fact, since I strongly dislike the "given" syntax, and really want
> that idea to be rejected, anything that increases its chances are a
> negative to me.
>
> Nevertheless, identifiers clashing with keywords isn't something brand
> new that only occurs thanks to "given". It has been a pain point
> forever. A small one, true, but still a nuisance.
>
> Verbatim names has the possibility to cut that nuisance value even
> further. But not if we short-sightedly limit it to a single case.




>
> > That's why I prefer the most modest solution of
> > only being able to escape given.
>
> Limiting a general method of mitigating the keyword clashing problem to
> a single keyword is as sensible as limiting the pathlib library to only
> work with a single hard-coded pathname.


>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/r1kFC8mYEKk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180518/62b49499/attachment.html>


More information about the Python-ideas mailing list