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/ Alex
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
