[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:
>> I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
>> a backslash rather than @ sign:
>> 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:
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
Another thought: I'm sure f-strings would have fun with this. This code
is currently illegal:
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.
More information about the Python-ideas