<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 2018-05-14 06:47 AM, Daniel Moisset wrote:<br>
<blockquote type="cite"
cite="mid:CALuYSZVGy-NpTC_LNQAtQ-Kvs5U1O-Ccu8nZqBBitki=K3hOWg@mail.gmail.com">
<div dir="ltr">
<div>Following up some of the discussions about the problems of
adding keywords and Guido's proposal of making tokenization
context-dependent, I wanted to propose an alternate way to go
around the problem.</div>
<div><br>
</div>
<div>My proposal essentially boils down to:</div>
<div>
<ol>
<li>The character "$" can be used as a prefix of
identifiers. formally,
<pre style="overflow-x:auto;overflow-y:hidden;padding:5px;background-color:rgb(238,255,204);color:rgb(51,51,51);line-height:18.528px;border:1px solid rgb(170,204,153);font-family:monospace,sans-serif;font-size:15.44px;border-radius:3px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><strong id="gmail-grammar-token-identifier">identifier </strong> ::= ["$"] <a class="gmail-reference gmail-internal" href="https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-xid_start" style="color:rgb(99,99,187);text-decoration:none" moz-do-not-send="true"><code class="gmail-xref gmail-docutils gmail-literal gmail-notranslate" style="background-color:transparent;padding:0px 1px;font-size:14.8996px;font-family:monospace,sans-serif;font-weight:normal;border-radius:3px"><span class="gmail-pre" style="hyphens: none;">xid_start</span></code></a> <a class="gmail-reference gmail-internal" href="https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-xid_continue" style="color:rgb(99,99,187);text-decoration:none" moz-do-not-send="true"><code class="gmail-xref gmail-docutils gmail-literal gmail-notranslate" style="background-color:transparent;padding:0px 1px;font-size:14.8996px;font-family:monospace,sans-serif;font-weight:normal;border-radius:3px"><span class="gmail-pre" style="hyphens: none;">xid_continue</span></code></a>*</pre>
</li>
<li>The "$" character is not part of the name. So the
program "foo=3;print($foo)" prints 3. So does the program
"$foo=3; print(foo)". Both set an entry to globals["foo"]
and keep globals["$foo"] unset. </li>
<li>if "$" appears in a token, it's always an identifier. So
"$with", "$if", "$return" are all identifiers.</li>
</ol>
<div>If you overcome the "yikes, that looks like
awk/bash/perl/php, and I don't like those", and consider it
as an escape for "unusual"/"deprecation" situations, I think
it's not a bad chose, and allows to a simple solutions to
many problems that have been in discussion recently and not
so recently. [examples below]</div>
</div>
<div><br>
</div>
<div>For me the benefits of this approach are:</div>
<div>
<ul>
<li>It's very simple to explain how to use and its semantics</li>
<li>It (seems to me it) should be easy to explain to a
python apprentice what a "$" means in code they read on a
book/blogpost/manual</li>
<li>It's very easy to implement, minimal changes in the
tokenizer</li>
<li>It's also easy to implement/integrate in other tools
(editors with syntax highlighters, code formatters, etc)</li>
<li>It is easy to see that it's 100% backwards compatible (I
understand that "$" has never been used in python before)</li>
<li>It is relatively unsurprising in the sense that other
languages are already using $ to label names (there may be
some point of confusion to people coming from javascript
where "$" is a valid character in names and is not
ignored). </li>
<li>It gives python devs and users a clear, easy and
universal upgrade path when keywords are added (language
designers: Add a __future__ import to enable keyword in
python N+1, add warnings to change kw --> $kw in python
N+2, and then turn it on by default in python N+3... ;
developers: add the import when they want to upgrade , and
fix their code with a search&replace when adding the
import or after getting a warning).</li>
<li>It allows you to use new features even if some libraries
were written for older python versions, depending the
deprecation period (this could be improved with sth I'll
write in another email, but that's the topic for another
proposal)</li>
<li>When clashes occur, which they always do, there's one
obvious way to disambiguate (see today the "class_"
argument for gettext.translation, the "lambd" argument for
random.expovariate, the "class_" filter in libraries like
pyquery for CSS class, functions like
pyquery, sqlalchemy.sql.operators.as_ , etc. Not counting
all the "cls" argument to every classmethod ever)</li>
<li>If we're worried about over proliferation of "$" in
code, I'm quite sure given past experience that just a
notice in PEP 8 of "only with $ in names to prevent
ambiguity" should be more than enough for the community</li>
</ul>
</div>
<div><br>
</div>
<div>What are the drawbacks that you find in this?</div>
<div>Best,</div>
<div> Daniel</div>
<br>
</div>
</blockquote>
For the record, C# does something similar to help interface with
other CLR languages with different keywords: any token starting with
@ is an identifier even if the unprefixed token would be a reserved
keyword. <br>
<br>
More on that:
<a class="moz-txt-link-freetext" href="https://ericlippert.com/2013/09/09/verbatim-identifiers/">https://ericlippert.com/2013/09/09/verbatim-identifiers/</a><br>
<br>
Alex<br>
<br>
</body>
</html>