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

Eric V. Smith eric at trueblade.com
Wed May 16 04:47:55 EDT 2018

On 5/16/18 4:13 AM, Paul Moore wrote:
> On 16 May 2018 at 01:41, 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'm missing something. How is that different from using a trailing
> underscore (like if_ or while_) at the moment? I understand that foo
> and \foo are the same name, whereas foo and foo_ are different, but
> how would that help?

Presumably things that know their name (like def'd functions and
classes, off the top of my head) would be able to figure out their
keyword-like name. Although exactly how that would work is debatable.

>>> def \if(): pass
...

Is \if.__name__ equal to r"\if", or "if"? Probably just "if".

Not that it really matters, but I can see code generators adding
backslashes everywhere. For example, in dataclasses I'd probably
generate __init__ for this:

\for=float
@dataclass
class C:
\if: int
only: \for

as:
def __init__(self, \if:\int, \only:\for):

That is, I'd add a backslash in front of every identifier, instead of
trying to figure out if I need to or not. I think a lot of code
generators (such as attrs) would need to be modified. Not a
show-stopper, but something to think about.

> Can you give a worked example of how this would
> help if we wanted to introduce a new keyword? For example, if we
> intended to make "where" a keyword, what would numpy and its users
> need to do to continue using numpy.where?

I think they'd have to change to numpy.\where when where became a
keyword.

Another thought: I'm sure f-strings would have fun with this. This code
is currently illegal:

>>> f'{\if}'
File "<stdin>", line 1
SyntaxError: f-string expression part cannot include a backslash

That would be a bear to fix, and would require all code that looks at
f-strings, even if only to ignore them, to change. Currently you can
just say "any string that has an f in front of it can be lexed (as a
unit) the same way 'r', 'u', and 'b' strings are". But this would break
that, and mean that instead of a simple tokenizer to find the end of an
f-string, you'd probably need a full expression parser. Again, just