[Python-ideas] Syntax idea: escaping names to avoid keyword ambiguity

Alexandre Brault abrault at mapgears.com
Mon May 14 11:28:36 EDT 2018

On 2018-05-14 06:47 AM, Daniel Moisset wrote:
> 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.
> My proposal essentially boils down to:
>  1. The character "$" can be used as a prefix of identifiers. formally, 
>     *identifier * ::= ["$"] |xid_start|
>     <https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-xid_start> |xid_continue|
>     <https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-xid_continue>*
>  2. 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. 
>  3. if "$" appears in a token, it's always an identifier. So "$with",
>     "$if", "$return" are all identifiers.
> 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]
> For me the benefits of this approach are:
>   * It's very simple to explain how to use and its semantics
>   * 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
>   * It's very easy to implement, minimal changes in the tokenizer
>   * It's also easy to implement/integrate in other tools (editors with
>     syntax highlighters, code formatters, etc)
>   * It is easy to see that it's 100% backwards compatible (I
>     understand that "$" has never been used in python before)
>   * 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). 
>   * 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).
>   * 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)
>   * 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)
>   * 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
> What are the drawbacks that you find in this?
> Best,
>    Daniel
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.

More on that: https://ericlippert.com/2013/09/09/verbatim-identifiers/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180514/961b2179/attachment-0001.html>

More information about the Python-ideas mailing list