[Python-ideas] Syntax idea: escaping names to avoid keyword ambiguity
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|
> 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
> * 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
> 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?
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...
More information about the Python-ideas