haael wrote:
As I said, I want sometimes to import some non-Python namespace, i.e. a Pascal program. If all identifiers are allowed, there would never be a clash of reserved words.
How do you import non-Python code? I don't understand this argument. [...]
So my change hits two birds with one stone: programmers could use any word as an identifier, developers could use any word as a token. Perfect solution.
On the contrary -- this would actually be a bad thing, in my opinion significantly worse than the current situation. I accept that name clashes can be a problem, but I dispute that it is a big problem. It's a tiny, minuscule problem, and I argue that your solution is much worse. You are only considering the *cost* of having reserved words and not the *benefit*. Your proposal increases the cognitive load on the programmer, rather than decreases it. We write code once, but we read it many times, and it is much more important to minimize the burden of reading code than writing it. The rule now is simple: there are a small number of reserved words. You may not use them, end of story. Therefore you can identify a reserved word *immediately* you see it, without caring about content beyond "is it inside a string or a comment?". The cognitive burden on the reader is very low. You would make that rule more complex. Reserved words would no longer be reserved. That alone is a bad thing -- you want to solve the problem that you can't name your variables "return", "for", "if", but I don't call that a problem, I call that a GOOD thing. I don't want to read code that sometimes uses return as a statement and sometimes as a variable. But worse, things which were a clear mistake before become ambiguous: len(.spam) is clearly an unambiguous mistake now, but with your proposal it becomes valid syntax. Now I have to stop and think: did the author mean .spam or did he mean obj.spam and just forget the obj part? If I don't use the dotted form, then Python might "steal" or "kidnap" (your words, not mine) my identifier, so if I care about forward compatibility, I will use dots everywhere: class .tree(.parent): def .func(self, .argument, .exception=None): if not .exception: return self.method(.argument, .param) raise .exception The cognitive load on reading my code is increased. The dots don't actually do anything, they're just there to protect my code from distant, *hypothetical* changes. If you think "nobody will bother to dot everything!" then you are inadvertently arguing that the problem you are trying to solve is a tiny problem that most people don't care about. -- Steven