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