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

M

metaperl

--> python -i 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?

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?
 
D

Diez B. Roggisch

metaperl said:
--> python -i
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?

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.

Most parsers are written in a way that makes keywords reserved,
regardless of their occurrence. That is because it is way easier to do
so. And the few reserved words won't matter usually.
Is Python 3k going to fix this sort of thing?

Don't think so.

Diez
 
R

Richard Brodie

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?

Because it's simpler to reserve words than worry about possible
ambiguities in all past and future use cases. If you could use it
as an identifier, it wouldn't be a reserved word by the normal
definition of the term.
 
I

Istvan Albert

metaperl said:
--> python -i
File "<stdin>", line 1
class = "algebra"
^
SyntaxError: invalid syntax

Designing a syntax to avoid all possible newbie errors is impractical
because as soon as you are finished with one iteration the new newbies
will start making different kinds of errors...

Take solace in the fact that you've been immediately notifed of the
error while its fix: renaming pass to passwd is trivial ...

i.
 
M

metaperl

Istvan said:
Designing a syntax to avoid all possible newbie errors is impractical
because as soon as you are finished with one iteration the new newbies
will start making different kinds of errors...

Take solace in the fact that you've been immediately notifed of the
error while its fix: renaming pass to passwd is trivial ...

The error message is not very explicit - "class is a reserved word"
will make far more sense to a new programmer than SyntaxError.
Especially since the expression is rather innocent looking and
correct-looking.
 
M

metaperl

Istvan said:
Designing a syntax to avoid all possible newbie errors is impractical
because as soon as you are finished with one iteration the new newbies
will start making different kinds of errors...

You are missing the point: the point is that the above could be
considered correct if the rules of Python were that an assignment
statement takes
IDENTIFIER '=' LVALUE

Also "class" IDENTIFIER COLON could also be considered correct.
Take solace in the fact that you've been immediately notifed of the
error while its fix: renaming pass to passwd is trivial ...

Again in certain automatic mapping circumstances (ORMs being the most
obvious, CSV to Python data another), it is not always convenient or
desirable or semantically articulate to do so.
 
S

Steve Holden

metaperl said:
The error message is not very explicit - "class is a reserved word"
will make far more sense to a new programmer than SyntaxError.
Especially since the expression is rather innocent looking and
correct-looking.
Well maybe, but one might as well have the interpreter complain that
'"=" is an invalid class name'. Once an unmatchable token is encountered
which parsing it's often difficult from inside the parser to determine
exactly what the programmer's intent was.

Otherwise you could try and fix the error, like the PL/1 F-level
compiler used to. This would usually work when all that was wrong was a
missing semicolon, but it frequently went completely berserk in other
cases, leading to strange and implausible error reports.

regards
Steve
 
R

Robert Hicks

metaperl said:
You are missing the point: the point is that the above could be
considered correct if the rules of Python were that an assignment
statement takes
IDENTIFIER '=' LVALUE

Also "class" IDENTIFIER COLON could also be considered correct.

Yes it could but it isn't and isn't likely to be. Simply do not use
reserved words. That rule is hardly limited to Python.

Robert
 
C

Cliff Wells

Yes it could but it isn't and isn't likely to be. Simply do not use
reserved words. That rule is hardly limited to Python.

I'm surprised so many people misunderstand his complaint. It isn't as
simple as "don't do it". The OP is referring to autogenerated code and
attributes. This means you must tell the source of the generated items
(perhaps a database table) that it can't have a column named "class" or
"pass" or add hacks in to work around it (an easy one would be to prefix
autogenerated attributes, which also helps work around the lack of
private attributes in Python).

Whether or not this should be changed is tangential to the OP's point.
It must be a bit frustrating to state the obvious over and over and see
it misinterpreted each time. Python has shortcomings. This is one of
them, whether there's valid reasons for it or not. It's better to
acknowledge it and offer something useful rather than "that isn't the
Python way, don't do it."


Cliff

--
 
C

Carl Banks

metaperl said:
--> python -i
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
 
A

Alex Martelli

Yes, keywords are always reserved. The one major language that tried to
do otherwise was PL/I, where you could code, e.g.:

if if = if then then = else else else = if

((of course, '=' was also polimorpically read as either assignment OR
comparison -- I gather that most Basic dialects still do that!-)).

IBM (PL/I's inventor and rabid defender) found out the hard way that
making the parser more complicated, slow and bug-prone in order to allow
such absurd obfuscation was NOT a popular trade-off -- despite IBM's
alleged monopoly power, PL/I is now basically dead while the older,
crankier languages that PL/I wanted to replace, Cobol and particularly
Fortran, are still quite alive (and with reserved words ALWAYS reserved
-- like in C, Python, Java, C#, Haskell, and basically every language
that's even halfway sensible;-).

Is Python 3k going to fix this sort of thing?

Fortunately not, or we'd all be busy studying Ruby or Boo!-)


Alex
 
A

Alex Martelli

metaperl said:
woe be unto the ORMs who try to map database columns to Python
attributes.

I'm gonna skip my usual anti-ORM rant, because there ARE valid case for
"mapping external names to Python identifiers" -- e.g., remote protocols
such as XML-RPC, automatic constructers of FF interfaces, etc. Such
code generators -- targeting ANY language currently alive -- obviously
have to possess some minimal knowledge of the target language's syntax,
and the obvious solution is to systematically transform identifiers
which would otherwise be keywords. The one most popular convention is
to append an underscore -- so that 'pass' becomes 'pass_', and so on.


Alex
 
A

Alex Martelli

Steve Holden said:
Otherwise you could try and fix the error, like the PL/1 F-level
compiler used to. This would usually work when all that was wrong was a
missing semicolon, but it frequently went completely berserk in other

Ah, yeah, I forgot that particularly endearing aspect of PL/I (to go
with the language having no keywords) -- many compilers bent over
backwards to double-guess what you meant, resulting in deep
misunderstandings by many programmers about what the language was
SUPPOSED to be, mysterious error messages and (worse!) program
misbehavior, etc etc -- all, of course, at the price of making the
compilers ever more intricate, bug-prone, extremely heavy in resource
cosumption, slow, and laughably bad at optimization (when compared to
compilers of the same era for sensibly SIMPLE languages, such as
Fortran).

Thanks for reviving the memories: it makes me SO ineffably glad that
nowadays I'm using a language which, among its guiding principles, has
"in the face of ambiguity, refuse the temptation to guess"!!!-)


Alex
 
R

Roy Smith

I'm gonna skip my usual anti-ORM rant, because there ARE valid case for
"mapping external names to Python identifiers" -- e.g., remote protocols
such as XML-RPC, automatic constructers of FF interfaces, etc. Such
code generators -- targeting ANY language currently alive -- obviously
have to possess some minimal knowledge of the target language's syntax,
and the obvious solution is to systematically transform identifiers
which would otherwise be keywords. The one most popular convention is
to append an underscore -- so that 'pass' becomes 'pass_', and so on.


Alex

Also, keywords are only reserved in the context of identifiers. They can
certainly appear as string literals used as dictionary keys:

attributes["class"] = "algebra"
 
C

Carl Banks

Alex said:
IBM (PL/I's inventor and rabid defender) found out the hard way that
making the parser more complicated, slow and bug-prone in order to allow
such absurd obfuscation was NOT a popular trade-off -- despite IBM's
alleged monopoly power, PL/I is now basically dead while the older,
crankier languages that PL/I wanted to replace, Cobol and particularly
Fortran, are still quite alive (and with reserved words ALWAYS reserved
-- like in C, Python, Java, C#, Haskell, and basically every language
that's even halfway sensible;-).

Except Fortran doesn't have any reserved words either:

PROGRAM KWDS
REAL REAL,WRITE
WRITE=1.0
REAL=2.0
WRITE(*,*)WRITE,REAL
END

(Not sure whether it's true in Fortran 9x.)


Carl Banks
 
R

Roy Smith

"Carl Banks said:
Except Fortran doesn't have any reserved words either:

PROGRAM KWDS
REAL REAL,WRITE
WRITE=1.0
REAL=2.0
WRITE(*,*)WRITE,REAL
END

(Not sure whether it's true in Fortran 9x.)


Carl Banks

As I remember, you didn't need the whitespace either. IIRC, your example
above could have been written as:

PROGRAMKWDS
REALREAL,WRITE
WRITE=1.0
REAL=2.0
WRITE(*,*)WRITE,REAL
END

and worked just as well. I have nightmares thinking about writing a
fortran parser. Oh yeah, spaces were the same as zeros on input, too.
What a wonderful language.

Isn't it wonderful how nothing you write ever gets lost once google gets
it's hands on it:

http://mirrorspace.org/python/doc/humor/index.html#habits

(personally, I think the one about the little girl buying a wabbit in the
pet store is the best of the collection).
 
P

Paddy

Cliff said:
I'm surprised so many people misunderstand his complaint. It isn't as
simple as "don't do it". The OP is referring to autogenerated code and
attributes. This means you must tell the source of the generated items
(perhaps a database table) that it can't have a column named "class" or
"pass" or add hacks in to work around it (an easy one would be to prefix
autogenerated attributes, which also helps work around the lack of
private attributes in Python).

Whether or not this should be changed is tangential to the OP's point.
It must be a bit frustrating to state the obvious over and over and see
it misinterpreted each time. Python has shortcomings. This is one of
them, whether there's valid reasons for it or not. It's better to
acknowledge it and offer something useful rather than "that isn't the
Python way, don't do it."


Cliff

--
Hi Cliff, You would also not be allowed to have a column name with a
space,comma,*,;,... in them. It might be best to assume that column
headings might end up with any arbitrary unicode character string and
program from that.
If the OP knows the full extent of his input data and knows that column
names are valid identifiers PLUS Python reserved words then yes, It
stops him from autogenerating identifiers in tht way - but others in
this thread have suggested work-arounds.

And yes, Python is not perfect, but its sweet spot is oh so tasty :)

(Which also applies to AWK, for a different sweet flavour)

- Paddy.
 
A

Antoon Pardon

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,835
Latest member
KetoRushACVBuy

Latest Threads

Top