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

[Carl Smith]

One problem with my proposal is with assignments to properties
(`name.keyword = something`) and regular assignments (including class and
def statements) inside the body of a class that subclasses and externally
defined class would all need to be allowed, so that inherited names can be
reassigned to and inherited methods can be overridden.

As there is no way to know from static analysis whether the code is
(legally) overriding something or (illegally) creating a name that is also
a keyword in that file, doing so would need to be handled by a runtime
exception, something like `NameError: cannot create names that are keywords
in the same context`.

Runtime errors still seem preferable to making keywords legally names in
the same file (especially if we have to escape the names).


-- Carl Smith
carl.input at gmail.com

On 16 May 2018 at 15:26, Carl Smith <carl.input at gmail.com> wrote:

> Thanks for the reply Todd.
>
> If `True` was redefined somewhere else, it would still be `True` for you.
> You could do `from oldlib import True as true` and have `true` equal `
> np.bool_(1)`. You could reference `oldlib.True` or do
> `oldlib.function(True=x)` to interact with the name in the old library.
>
> None of this would actually apply to `True`, as it's a reserved word in
> all versions. The proposal only applies to new keywords that are used as
> names in other libraries.
>
> Again, thanks for taking the time.
>
> -- Carl Smith
> carl.input at gmail.com
>
> On 16 May 2018 at 14:46, Todd <toddrjen at gmail.com> wrote:
>
>> On Tue, May 15, 2018, 23:03 Carl Smith <carl.input at gmail.com> wrote:
>>
>>>
>>>
>>>> On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano <steve at pearwood.info>
>>>> wrote:
>>>>
>>>>> Inspired by Alex Brault's  post:
>>>>>
>>>>> https://mail.python.org/pipermail/python-ideas/2018-May/050750.html
>>>>>
>>>>> I'd like to suggest we copy C#'s idea of verbatim identifiers, but
>>>>> using
>>>>> a backslash rather than @ sign:
>>>>>
>>>>>     \name
>>>>>
>>>>> would allow "name" to be used as an identifier, even if it clashes
>>>>> with
>>>>> a keyword.
>>>>
>>>>
>>> I strongly disagree, but can't seem to get anyone
>>> ​ to bite.
>>>
>>> We want to be able to introduce a keyword that was formally a name, still
>>> allow
>>> it to be used as a name, still allow code that uses it as a keyword to
>>> interoperate
>>> ​ ​
>>> with code that uses it as a name
>>> , without changing the language
>>> or implementation
>>> too much.
>>>
>>> ​Ideally, Python would still not allow the keyword to be used as a name
>>> and a
>>> keyword in the same file??
>>>
>>> The lexer could class the tokens as *keynames*, and the parser could
>>> use the
>>> context of the first instance of each keyname to determine if it's a
>>> name or
>>> keyword for the rest of that file. Projects that used the word as a name
>>> would
>>> only be prevented from also using it as a keyword in the same file.
>>>
>>> It's really then a question of whether users could elegantly and
>>> naturally
>>> reference a name in another module without introducing the name to the
>>> current module's namespace.
>>>
>>> We only reference external names (as syntactic names) in import
>>> statements,
>>> as properties after the dot operator, and as keyword arguments.
>>>
>>> If code that used the word as a keyword was still allowed to use the
>>> word as
>>> a name after the dot operator and as a keyword argument *in an
>>> invocation*,
>>> it would only change the language in a subtle way.
>>>
>>> If we could reference keynames in import statements, but not import the
>>> name,
>>> so basically allow `from keyname import keyname as name`, but not allow
>>> `import keyname`, we could still easily import things that used the
>>> keyname
>>> as a name. This wouldn't change the language too dramatically either.
>>>
>>> Maybe I'm just being dumb, but it seems like three subtle changes to the
>>> language would allow for everything we want to have, with only minor
>>> limitations
>>> on the rare occasion that you want to use the new keyword with a library
>>> that is
>>> also using the same keyword as a name.
>>>
>>> I promise not to push this idea again, but would really appreciate
>>> someone taking
>>> a couple of minutes to explain why it's not worth responding to. I'm not
>>> offended,
>>> but would like to know what I'm doing wrong.
>>>
>>> Thanks.
>>>
>>
>>
>> I think your idea would work okay if everyone followed good programming
>> practices.  But when you have files that are tens of thousands of ugly code
>> written by dozens of non-programmers over a dozen years it sounds like a
>> recipe for a nightmare.
>>
>> For example someone you never met that left your group ten years ago
>> could have made "True" be "np.bool_(1)" on a whim that makes your code
>> break later in very hard-to-debug ways.
>>
>> To put it simply, I think it encourages people to take convenient
>> shortcuts with implications they don't understand.
>>
>>>
>> _______________________________________________
>> 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/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180516/42308da6/attachment.html>