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/
