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

[Carl Banks]

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?  :)

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)

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


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

In fact, the opposite is going to happen: the one keyword that can
currently moonlight as a symbol, "as", is going to become a full-time
keyword in Python 3000.


> woe be unto the ORMs who try to map database columns to Python
> attributes.

A ha.  First of all, consider whether you ought to be using dictionary
keys instead.  That is, columns["Name"] rather than columns.Name.  It
most cases keys are preferrable, because unless you know what the
columns are ahead of time, you'll be using getattr and setattr to get
at the attributes, which defeats the whole point of attributes.  (And
if you do know what the columns are ahead of time, no need to
automatically map the names.)

The one legitimate use case I can think of for wanting to use
attributes instead of keys is if you intend to have user-supplied
Python code operating on the columns (and even then you should consider
whether the user would be better off using keys).  In this case you're
pretty much stuck with workarounds.

You can automatically rename any keywords when mapping the column
names, and advise the user that colums with keyword names will have
(for example) and appended underscore:

import keyword

def column_attribute_name(name):
    if keyword.iskeyword(name):
        return "%s_" % name
    return name


Carl Banks