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

[Steven D'Aprano]

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?


> 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.


> 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