OK, that was a silly joke, but did you realize that the following already WORKS TODAY:
>>> class Foo: ... pass >>> f = Foo() >>> f.__dict__["if"] = 42 >>> f.๐ข๐ 42 That's right, I can access a member whose name is a keyword by simply using Unicode bold. Because Python normalizes Unicode fonts but this is apparently AFTER keywords have been recognized. Stephan 2018-05-17 19:53 GMT+02:00 Stephan Houben <stephan...@gmail.com>: > Fortunately we have Unicode bold characters nowadays > > ๐ข๐ if ๐ข๐ง in: > ๐ซ๐๐ญ๐ฎ๐ซ๐ง return > > Look ma! No syntactic ambiguity! > > Stephan > > 2018-05-17 19:10 GMT+02:00 Chris Barker via Python-ideas < > python-ideas@python.org>: > >> On Wed, May 16, 2018 at 2:09 PM, Carl Smith <carl.in...@gmail.com> wrote: >> >>> If your position is that Guido shouldn't introduce keywords that are >>> currently used as names at all, >>> >> >> Exactly -- which is why I'm wondering my no one (that I've seen -- long >> thread) is presenting the backwards option: >> >> Any new keywords introduced will be non-legal as regular names. >> >> \new_key_word >> >> for instance. >> >> Makes me think that it may have been good to have ALL keywords somehow >> non-legal as user-defined names -- maybe ugly syntax, but it would make a >> clear distinction. >> >> how ugly would this be? >> >> \for i in range(n): >> \while \True: >> ... >> >> pretty ugly :-( >> >> But maybe not so much if only a handful of new ones.... >> >> Or is there another currently illegal character that could be used that >> would be less ugly? >> >> I'm actually confused as to what the point is to the \ prefix idea for >> names: >> >> * It would still require people to change their code when a new keyword >> was introduced >> >> * It would be no easier / harder than adding a conventional legal >> character -- trailing underscore, or ??? >> >> * but now the changed code would no longer run on older versions of >> python. >> >> I guess it comes down to why you'd want to call out: >> >> "this is a name that is almost like a keyword" >> >> Seems like a meh, meh, lose proposal to me. >> >> OK, I see one advantage -- one could have code that already has BOTH word >> and word_ names in it. So when word becomes a keyword, a tool that >> automatically added an underscore would break the code. whereas if it >> automatically added an currently illegal character, it wouldn't shadow >> anything. >> >> But a sufficiently smart tool could get around that, too. >> >> -CHB >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/