On Sun, 16 Oct 2022 at 21:19, Antoon Pardon <antoon.par...@vub.be> wrote: > > Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com: > > This has been discussed so often precisely because I swear NO CHOICE of > > keyword would satisfy everybody! Most languages start with designated > > keywords and some reserve a few for later use. But then things can get > > frozen in place to avoid breaking existing programs or break older > > compilers/interpreters. > > > > Some languages use techniques to extend themselves more harmlessly such as > > creating a singleton object that has content that can be regular data as in > > math.pi, or functions/methods or new ides like "Symbols" that allow all > > kinds of extensions to the language in a fairly harmless way as no older > > program would likely have used features that did not exist. > > > > That might not easily solve this problem. But I wonder if reserving some > > kind of prefix might help, so anything like extension.0nNoBreak could be > > added to a loop as a final clause and be treated as a non-key keyword of > > sorts. > > My idea would be to reserve different unicode blocks for the keywords > and the identifiers. e.g. We could reserve the mathematical alphanumeric > block for keywords and all other letters and numbers for identifiers. > Doing so would allow extenting the keywords without breaking programs > that already use that combination as an identifier.
Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers Briefly, what it means is that (aside from some backward compatibility special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks, it's by types. It's way WAY too late to change what's allowed for identifiers, as you will potentially be breaking programs that use the current rules. > Python could slowly transition in this direction by first allowing the > current keywords to be in this block. Every new keyword would only be in > that unicode block. If would then be possible to write python code with > this convention but it wouldn't be obligatory. After some time the > python developers could decide to make it obligatory. Obligatory??? Please explain how you intend to convince the entire world that non-ASCII code is an acceptable requirement. Explain to me how you're going to go to every text editor and ensure that it supports easy entry of Python keywords that aren't ASCII. And please explain how this is even better. > I doubt this will idea will get from the ground, but I think it would > allow for a smoother transition into new concepts, as it is no longer a > strugle searching for a keyword that will break as little programs as > possible. Yeah it won't. Good luck though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
