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

[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]

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

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.

 

[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]

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

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]

One way to avoid the issue I brought up is for the syntax to be very
regular... like Lisp or Tcl:

set class "algebra"

(setq class "algebra")

 

[Grant Edwards]

One way to avoid the issue I brought up is for the syntax to
be very regular... like Lisp or Tcl:

set class "algebra"

(setq class "algebra")

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.

 

[Cliff Wells]

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?


Cliff

 

[Fredrik Lundh]

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.padoan]

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.

Maybe that is a good argumment for Py.Test

 

[Kay Schluehr]

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):
That's all still LL(1) parsable.

 

[projecktzero]

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

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]

patch here:

http://mail.python.org/pipermail/python-list/2001-June/047996.html

</F>

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.