<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-forward-container">On 13/05/2018 19:19, Guido van
Rossum wrote:<br>
<blockquote type="cite"
cite="mid:CAP7+vJLhLZufLZW_4HCi7qnjReCMsRVtz14sq4MAYf+BT=Hqag@mail.gmail.com">
<div dir="ltr">
<div>As anyone still following the inline assignment
discussion knows, a problem with designing new syntax is
that it's hard to introduce new keywords into the language,
since all the nice words seem to be used as method names in
popular packages. (E.g. we can't use 'where' because there's
<a
href="https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.html"
moz-do-not-send="true">numpy.where</a>, and we can't use
'given' because it's used in <a
href="http://hypothesis.readthedocs.io/en/latest/quickstart.html"
moz-do-not-send="true">Hypothesis</a>.)</div>
<div><br>
</div>
<div>The idea I had (not for the first time :-) is that in
many syntactic positions we could just treat keywords as
names, and that would free up these keywords.</div>
<div><br>
</div>
<div>For example, we could allow keywords after 'def' and
after a period, and then the following would become legal:</div>
<div><br>
</div>
<div>class C:</div>
<div> def and(self, other):</div>
<div> return ...</div>
<div><br>
</div>
<div>a = C()</div>
<div>b = C()<br>
</div>
<div>print(a.and(b))</div>
<div><br>
</div>
<div>This does not create syntactic ambiguities because after
'def' and after a period the grammar *always* requires a
NAME.</div>
<div><br>
</div>
<div>There are other positions where we could perhaps allow
this, e.g. in a decorator, immediately after '@' (the only
keyword that's *syntactically* legal here is 'not', though
I'm not sure it would ever be useful).</div>
</div>
</blockquote>
So you would be allowing "second class" identifiers - legal in
some positions where an identifier is allowed, not legal in
others.<br>
With respect, that seems like a terrible idea; neither those who
want to use such identifiers, nor those who don't, would be
happy. Especially if it encourages work-arounds such as<br>
<br>
def and(x, y):<br>
<div> return ...</div>
<div><br>
</div>
# and(1,2) # Oops, SyntaxError. Oh, I know:<br>
globals()['and'](1,2) # Works!<br>
<br>
and a zillion others. <br>
<blockquote type="cite"
cite="mid:CAP7+vJLhLZufLZW_4HCi7qnjReCMsRVtz14sq4MAYf+BT=Hqag@mail.gmail.com">
<div dir="ltr"><br>
<div>[snip] And it would probably cause certain typos be
harder to diagnose.</div>
</div>
</blockquote>
No doubt.<br>
<blockquote type="cite"
cite="mid:CAP7+vJLhLZufLZW_4HCi7qnjReCMsRVtz14sq4MAYf+BT=Hqag@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>I should also mention that this was inspired from some
messages where Tim Peters berated the fashion of using
"reserved words", waxing nostalgically about the old days of
Fortran (sorry, FORTRAN), which doesn't (didn't?) have
reserved words at all (nor significant whitespace, apart
from the "start in column 7" rule).</div>
<div><br>
</div>
<div>Anyway, just throwing this out. Please tear it apart!<br>
</div>
</div>
</blockquote>
Thanks. <span class="moz-smiley-s1"><span>:-)</span></span><br>
<blockquote type="cite"
cite="mid:CAP7+vJLhLZufLZW_4HCi7qnjReCMsRVtz14sq4MAYf+BT=Hqag@mail.gmail.com">
<div dir="ltr">
<div><br>
-- <br>
<div class="gmail_signature"
data-smartmail="gmail_signature">--Guido van Rossum (<a
href="http://python.org/%7Eguido" target="_blank"
moz-do-not-send="true">python.org/~guido</a>)</div>
</div>
</div>
<br>
</blockquote>
Best wishes<br>
Rob Cliffe<br>
</div>
</body>
</html>