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

Thu May 17 18:07:27 EDT 2018

On Thursday, May 17, 2018 at 5:40:05 PM UTC-4, Carl Smith wrote:
>
> > 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.
>
> This assumes that every library that defines something named `where` (and 
> every library that references it)
> are maintained. If the parser just starts treating `where` as a keyword, 
> working code will not parse. That
> may be acceptable (I don't know what the policy is), but it makes 
> introducing keywords more costly than
> an approach that allows old code to continue working.
>

Fair enough.

If that solution is taken, I want the linters to complain about verbatim 
uses as a stopgap measure that ultimately should be removed.  I don't think 
interfaces should be naming functions and arguments: "if", "while", etc.  I 
think PEP 08 should discourage its use as well except when it's necessary 
to continue to use an unmaintained interface.

> -- Carl Smith
> carl.... at gmail.com <javascript:>
>
> On 17 May 2018 at 19:41, Neil Girdhar <miste... at gmail.com <javascript:>> 
> wrote:
>
>> 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>:
>>>
>>>> On Wed, May 16, 2018 at 2:09 PM, Carl Smith <carl.... at gmail.com> 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
>>>>
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python... at python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>>
>>>
>> _______________________________________________
>> 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/d0c31f55/attachment-0001.html>