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

[Neil Girdhar]

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

> On Thu, May 17, 2018 at 11:02:23PM -0400, Neil Girdhar wrote:
>
> > However, the difference between the backslash syntax and comprehensions
> and
> > generator functions is that comprehensions and generator functions make
> the
> > language more expressive.  The backslash is no more expressive than
> > trailing underscore.  It's no more succinct, and no more clear.  Adding
> it
> > to the language constitutes more that the user needs to learn, which
> makes
> > Python slightly less accessible.
>
> On the contrary: it removes a pain point when dealing with external
> libraries. No longer will we have to *transform* the name on both input
> and output. Instead, we only need to *escape* the name when written as a
> literal.
>
>
> > 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
>
> and maybe even occasionally class_ :-)
>
> Or they use a synonym:
>
>     kind, clade, type (with or without trailing underscore).
>
> I've seen *every one of those choices* in real code. Except "clade", I
> just added that one now.
>
> 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


>
>
> > There is already
> > probably billions of lines of code that use trailing underscore to avoid
> > collisions.
>
> Indeed, and if this proposal is accepted, that will remain legal, and if
> people want to write class_ instead of \class or klass, or if_ instead
> of \in or infile, they are permitted to do so.


> You can even have your own in-house style rules mandating whatever style
> you prefer.
>
>
> > If the backslash syntax is added, then there will be a natural
> > push towards the "right way" to avoid collisions.   If that's
> backslashes,
> > then projects are typically going to have code written with backslashes
> and
> > code written with underscore.  When you go access a variable named
> "where",
> > you'll wonder: was it called "\where" or "where_"?
>
> Yes? Why is this more of a problem than what we have now? Is it called
> (in context of PEP 572) "where" or "given"? In general, is it called:
>
>     where, place, location, loc, locus, position, pos, x, xy,
>     locality, locale, coordinates, coord
>
> or some other synonym?
>
> In order to successfully use a library's API, one needs to actually
> know what that API *is*. That means you need to know the name of things.
> Adding verbatim names won't change that.
>
>
> > Maybe the "\where" is pretty enough that it's worth it like you say.
> Maybe
> > a function like:
> >
> > def f(\in=0, out=1):
> >
> > is prettier than
> >
> > def f(in_=0, out=1):
> >
> > but I'm already so used the current way of doing things, my aesthetic is
> > that it's not worth the variability.
>
> Being able to use "in" as an identifier as in that example is not the
> driving motivation for adding this feature. The driving motivation is to
> remove a pain point when dealing with external APIs that use keywords as
> regular identifiers, and to make it simpler to future-proof code when a
> new keyword is due to be introduced.
>
> Nobody is going to recommend that folks rush to deprecate their name_
> APIs and replace them with \name. I'm sure most library maintainers
> will have better things to do. in_ will stay in_ for most existing code.
> It is only new code that doesn't have to care about 3.7 or older than
> can even consider this.
>
>
> > For that reason, I'd like to make a more modest proposal to *only* add a
> > verbatim versions of keywords as necessary,
>
> Because "special cases are special enough to break the rules, complicate
> the documentation and the implementation, and give rise to a thousand
> Stackoverflow posts asking why we can escape some keywords but not
> others".
>
>
>
> > e.g., "\where" or "\given".
> > That way, there will be no temptation to use that syntax in any other
> > place.
>
> Just because you have no use-case for using "except", say, as an
> identifier doesn't mean nobody has. You are not arbiter of which
> keywords are acceptable to use verbatim and which ones are forbidden.
>

All of your arguments would have applied to a keyword escaping proposal had
it been proposed before "given" was even considered.  The only reason we're
even considered considering escaping is to keep code that uses "given" as
an identifier working.  That's why I prefer the most modest solution of
only being able to escape given.  After all, there wasn't any big need to
escape other keywords last year.

>
> > When 3.7 hits end-of-life, the "\given" (or whatever) can be deprecated.
>
> Having a white list of "Permitted keywords you may escape" is horrible
> enough without baking in a policy of continued code churn by removing
> them from the whitelist every few releases.


>
>
> --
> 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/8f4049bf/attachment-0001.html>