Are Python's reserved words reserved in places they dont need to be?
metaperl
>>> 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?
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?
Diez B. Roggisch
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
Richard Brodie
"metaperl" <meta...@gmail.com> wrote in message
news:1158072199.6...@p79g2000cwp.googlegroups.com...
> 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.
Istvan Albert
> --> python -i
> >>> class = "algebra"
> 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.
metaperl
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.
metaperl
Diez B. Roggisch wrote:
> metaperl schrieb:
> > --> 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
> the few reserved words won't matter usually.
woe be unto the ORMs who try to map database columns to Python
attributes.
metaperl
Istvan Albert wrote:
> metaperl wrote:
> > --> python -i
> > >>> class = "algebra"
> > 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...
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.
>
> i.
Steve Holden
'"=" 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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Robert Hicks
metaperl wrote:
> Istvan Albert wrote:
> > metaperl wrote:
> > > --> python -i
> > > >>> class = "algebra"
> > > 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...
>
> 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
Cliff Wells
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
--
Carl Banks
> --> 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
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
Alex Martelli
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
Alex Martelli
> 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
Roy Smith
al...@mac.com (Alex Martelli) wrote:
Also, keywords are only reserved in the context of identifiers. They can
certainly appear as string literals used as dictionary keys:
attributes["class"] = "algebra"
Carl Banks
> 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
Roy Smith
"Carl Banks" <pavlove...@gmail.com> wrote:
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).
Paddy
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.
Antoon Pardon
> 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
Paul Rubin
> 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.
Heh, sounds like ColorForth, in which words meant different things
depending on what color they were written in (www.colorforth.com).
Madness, if you ask me ;-).
Antoon Pardon
Well I'm sure people would be able the abuse the feature with
madness as a result. However that is nothing new.
One place where I would use such a feature is in a unittest
package. I think being able to write self.assert or self.raise
looks better than having to append an underscore.
I once experimented with end markers in python, but I dropped
it because end.if wasn't legal python.
If python would make this distinction, one wouldn't need
to be concerned anymore that the introduction of a new
keyword would break code.
--
Antoon Pardon
Fredrik Lundh
> One place where I would use such a feature is in a unittest
> package. I think being able to write self.assert or self.raise
> looks better than having to append an underscore.
patch here:
http://mail.python.org/pipermail/python-list/2001-June/047996.html
</F>
John Roth
I can give you a categorical NO to that one. Unless
Guido changes his mind, and it's very unlikely, the
answer is in PEP 3099: "Things that will not change
in Python 3000". It says: "The parser won't be more
complex than LL(1)." He does not want to start down
the slippery slope that leads to certain unnamed
languages such as Perl.
John Roth
metaperl
regular... like Lisp or Tcl:
set class "algebra"
(setq class "algebra")
Grant Edwards
Unfortunately (or fortunately?) the human mind isn't very
regular and seems to prefer structured, redundant, and
irregular languages. One might suppose it makes pattern
recognition by neural networks easier.
--
Grant Edwards grante Yow! I am having a
at CONCEPTION--
visi.com
Cliff Wells
> Antoon Pardon wrote:
>
> > One place where I would use such a feature is in a unittest
> > package. I think being able to write self.assert or self.raise
> > looks better than having to append an underscore.
>
>
> http://mail.python.org/pipermail/python-list/2001-June/047996.html
Did you happen to remember this post or is Google *really* your friend?
Cliff
Fredrik Lundh
>> patch here:
>>
>> http://mail.python.org/pipermail/python-list/2001-June/047996.html
>
> Did you happen to remember this post or is Google *really* your friend?
Have you taken The Oath? If not, I'm afraid I cannot tell you.
</F>
eduardo...@gmail.com
> package. I think being able to write self.assert or self.raise
> looks better than having to append an underscore.
Maybe that is a good argumment for Py.Test ;)
Kay Schluehr
Carl Banks 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? :)
Yeah. But elimination of all keywords and replacement by punctuation is
clearly an alternative. One might just start with:
@class X(object):
@def __init__(self):
@print "an X"
and move on to:
@% X(object):
@_ _init__(self):
>> "an X"
That's all still LL(1) parsable.
projecktzero
Yikes! I'm color blind! (I've heard that 10% of the male population is
color blind.) I'd be a very poor ColorForth programmer. =)
Andrew McLean
>
> 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
>
It's stranger than that. FORTRAN 77 is insensitive to white space (other
than inside character literals).
So you could write the code like:
P RO G RAM KW D S
RE ALRE AL, WRITE
WRITE = 1 . 0
RE AL=2.0
WRI TE(* , *)WRI TE, REAL
E N D
if you wanted to ;-)
When people complain that Python is sensitive to white space, remember
this as the opposite extreme!
[Just for completeness I will add that there are rules about what
"columns" the code has to be in, but that is separate from the white
space issue.]
NickC
Heh. Imagine how much more fun the introduction of conditional
expressions and the yield statement -> yield expression transition in
Python 2.5 would have been if Python 2.4 had used this behaviour :)
Cheers,
Nick.