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:


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:

class C:
    \if: int
    only: \for

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.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to