Are Python's reserved words reserved in places they dont need to be?
apardon at forel.vub.ac.be
Wed Sep 13 08:51:55 CEST 2006
On 2006-09-13, Carl Banks <pavlovevidence at gmail.com> wrote:
> metaperl wrote:
>> --> python -i
>> >>> class = "algebra"
>> File "<stdin>", line 1
>> class = "algebra"
>> SyntaxError: invalid syntax
>> Why isn' t the parser smart enough to see that class followed by an
>> identifier is used for class definition but class followed by equals is
>> a simple assignment?
> Hmm. Someone called "metaPERL" is asking why Python doesn't have a
> more complicated grammar. Why does this not surprise me? :)
Would a solution for this always make the grammer more complicated?
> Seriously, Python is that way deliberately. The developers consider it
> a good design to reserve keywords. It is not in any way considered a
> flaw, nor an oversight, nor a case of laziness.
> Besides, what you ask is impossible in general. Consider this code:
This is just an idea of mine, nothing I expect python to adapt.
But just suppose the language allowed for words in bold. A word
in bold would be considered a reserved word, a word in non bold
would be an identifier.
> Are you returning the tuple (1,2,3), or are you calling the function
> "return" with arguments 1,2,3? There is no context-free grammar in the
> universe that can divine which one is meant. It'd have to use context
> to even guess, and in a highly dynamic language like Python, you can
> never be wholly sure of the context. (Is there an identifier named
> "return" in scope? Don't know until you run the code...)
With my idea, you would just look whether "return" was written in
bold or not.
>> Also, I had a bug where I tried to set the attributes "user" and "pass"
>> in an object but "pass" would not work because it is a reserved word.
>> Again pass should be reserved in certain contexts but not others.
>> Is Python 3k going to fix this sort of thing?
> Nope. PEP 3099 (which lists changes that won't be made in Python
> 3000), states that the Python grammar will not be more complex than
> LL(1), and says that simple grammars are more desirable than complex
> ones. There is no hope of this being "fixed".
This idea won't make python more complex than LL(1).
More information about the Python-list