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

On 5/16/18 4:13 AM, Paul Moore wrote:

On 16 May 2018 at 01:41, Steven D'Aprano <st...@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 something to think about.

Eric
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/