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

[Eric V. Smith]

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 
something to think about.

Eric