On Thu, May 17, 2018 at 9:35 PM Steven D'Aprano <steve@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@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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.