Are Python's reserved words reserved in places they dont need to be?

[Antoon Pardon]

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:
>
> return(1,2,3)

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).

-- 
Antoon Pardon