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

[Neil Girdhar]

On Thu, May 17, 2018 at 9:35 PM Steven D'Aprano <steve at pearwood.info> wrote:

> On Thu, May 17, 2018 at 11:41:33AM -0700, Neil Girdhar wrote:
> > My preference is to do nothing.  If you end up making "where" a keyword
> in
> > Python 3.8, numpy will probably:
>
> This is only incidently about "where". I'm hoping that the "where" (or
> "given") proposal is rejected. It is so verbose and redundantly
> repetitious in the common case that rather than being an improvement
> over the status quo, it is worse. But that's by-the-by.
>
>
> > * rename their where function to "where_" in 3.8
> > * add a where_ alias in Python < 3.8.
> >
> > And then people will have to fix their code in 3.8 anyway.  Only instead
> of
> > learning a new verbatim syntax, they will just add the familiar
> underscore.
>
> You should be thinking forward two or three versions from now, when
> \name is the familiar syntax and name_ looks like you started to write
> an identifier using the underscore_words_convention but got distracted
> halfway through.
>
> Remember that (if approved) verbatim names will not be "that new syntax"
> for long. We don't still talk about "that new fangled list comprehension
> syntax" or "that new yield keyword". That was the problem with the "old
> versus new style classes" terminology: at the point that "new-style
> classes" had been around for six releases, approaching a decade, they
> weren't new any more.
>
> I can get behind the benefit of main benefit of backslash, which is
keeping code working with old libraries.

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.

I don't like multiple ways of doing the same thing.  There is already
probably billions of lines of code that use trailing underscore to avoid
collisions.  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_"?

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.

For that reason, I'd like to make a more modest proposal to *only* add a
verbatim versions of keywords as necessary, e.g., "\where" or "\given".
That way, there will be no temptation to use that syntax in any other
place.  If a new version of Python comes out with a new keyword, say "abc",
then all of the old Python versions can get a minor revision that knows
about "\abc".  This would ensure that the backslash syntax is only used to
avoid collisions with new keywords.

When 3.7 hits end-of-life, the "\given" (or whatever) can be deprecated.


> > One thing that should ideally be done is to improve the SyntaxError
> > processing to special case use of keywords in places that identifiers
> are
> > used.
>
> This is worth doing regardless of whether or not we get verbatim strings
> or some other alternative. You ought to raise it on the bug tracker.
>
>
>
> --
> 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/20180517/5315e981/attachment-0001.html>