[Python-ideas] Verbatim names (allowing keywords as names)
steve at pearwood.info
Fri May 18 02:47:30 EDT 2018
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
> 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
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
> 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
> e.g., "\where" or "\given".
> That way, there will be no temptation to use that syntax in any other
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.
More information about the Python-ideas