Python3k extended grammar
Roy Katz
katz at Glue.umd.edu
Thu May 18 14:53:56 EDT 2000
Hi!
(apologies in advance as to the applicability of this message to such a
general group)
I checked out the TYPE-SIG material.. It's really interesting.
I agree that grammars which take into account the type of an object are
in quite demand in Python; however, as a (practical) programmer I take
offense at the creation of (yet) more keywords and operators. For
example, take the function declaration grammar:
def func( x: Integer, y: Integer ) -> Integer:
what's the rational behind using the -> operator, rather than sticking to
'return'?
def func( x, y ) return Integer:
IMHO it's just another operator or keyword to bloat my language.
Same thing with the proposed 'decl' operator. Why another keyword?
What's wrong with the following:
int = Integer
def add( (int) x, (int) y ) # specifies type of the parameter
return int; # specifies the return type
raise exGenException: # specifies the exceptions thrown
z = x + y # body
return z # exit.
No added keywords there. I understand that the above is more verbose,
however, I believe this approach is vastly more consistent with the
traditional grammar. Then again, this is only my personal preference.
Another question: to whoever proposed the following notation:
x: [ Integer ]
what happens when we have a list of list of strings?
x: [[ StringType ]]
am I correct here?
As I see it, we have a grammar spectrum with Pascal and Java on one side,
(which places the burden on the programmer to declare, detail and
categorize every little nuance), and perl on the other -- a language
which IMHO is reconfigurable ad nauseum. (what kind of situation
necessates changing the starting array index from 0, anyway?).
Roey Katz
Jewish Programmer.
Oy.
More information about the Python-list
mailing list