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

[Neil Girdhar]

My preference is to do nothing.  If you end up making "where" a keyword in 
Python 3.8, numpy will probably:
* 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.

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.  Instead of:

In [1]: for if in range(10):
  File "<ipython-input-1-a51677fa6668>", line 1
    for if in range(10):
         ^
SyntaxError: invalid syntax

How about

In [1]: for if in range(10):
  File "<ipython-input-1-a51677fa6668>", line 1
    for if in range(10):
         ^
SyntaxError: "if" was used where a variable belongs, but "if" is a 
keyword.  Consider using "if_" instead.

Similarly,

In [2]: int.if
  File "<ipython-input-2-72291900e846>", line 1
    int.if
         ^
SyntaxError: "if" was used where an attribute name belongs.  Did you mean 
"if_"?

SyntaxError doesn't need to quickly generate its error strings.  So there 
is only an upside to having clear error messages.

On Thursday, May 17, 2018 at 1:54:42 PM UTC-4, Stephan Houben wrote:
>
> Fortunately we have Unicode bold characters nowadays
>
> 𝐢𝐟 if 𝐢𝐧 in:
>     𝐫𝐞𝐭𝐮𝐫𝐧 return
>
> Look ma! No syntactic ambiguity!
>
> That's hilarious :) 

> Stephan
>
> 2018-05-17 19:10 GMT+02:00 Chris Barker via Python-ideas <
> python... at python.org <javascript:>>:
>
>> On Wed, May 16, 2018 at 2:09 PM, Carl Smith <carl.... at gmail.com 
>> <javascript:>> wrote:
>>
>>> If your position is that Guido shouldn't introduce keywords that are 
>>> currently used as names at all,
>>>
>>
>> Exactly -- which is why I'm wondering my no one (that I've seen -- long 
>> thread)  is presenting the backwards option:
>>
>> Any new keywords introduced will be non-legal as regular names.
>>
>> \new_key_word
>>
>> for instance.
>>
>> Makes me think that it may have been good to have ALL keywords somehow 
>> non-legal as user-defined names -- maybe ugly syntax, but it would make a 
>> clear distinction.
>>
>> how ugly would this be?
>>
>> \for i in range(n):
>>     \while \True:
>>         ...
>>
>> pretty ugly :-(
>>
>> But maybe not so much if only a handful of new ones....
>>
>> Or is there another currently illegal character that could be used that 
>> would be less ugly?
>>
>> I'm actually confused as to what the point is to the \ prefix idea for 
>> names:
>>
>> * It would still require people to change their code when a new keyword 
>> was introduced
>>
>> * It would be no easier / harder than adding a conventional legal 
>> character -- trailing underscore, or ???
>>
>> * but now the changed code would no longer run on older versions of 
>> python.
>>
>> I guess it comes down to why you'd want to call out:
>>
>> "this is a name that is almost like a keyword"
>>
>> Seems like a meh, meh, lose proposal to me.
>>
>> OK, I see one advantage -- one could have code that already has BOTH word 
>> and word_ names in it. So when word becomes a keyword, a tool that 
>> automatically added an underscore would break the code. whereas if it 
>> automatically added an currently illegal character, it wouldn't shadow 
>> anything.
>>
>> But a sufficiently smart tool could get around that, too.
>>
>> -CHB
>>
>>
>> -- 
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115       (206) 526-6317   main reception
>>
>> Chris.... at noaa.gov <javascript:>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python... at python.org <javascript:>
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180517/9bd3e556/attachment-0001.html>