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

Todd toddrjen at gmail.com
Wed May 16 09:46:43 EDT 2018

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180516/278a2691/attachment-0001.html>

More information about the Python-ideas mailing list