Bruno Desthuilliers wrote:
> Yes. Python deliberately choosed to be a statement-based language.
>
>> Why not use the = operator like most other assignments?
>
> This dead horse has been beaten to hell and back.
>
> Note that as far as I'm concerned, I may like an expression-based
> Python-inspired language. But this is another story.
My bad! In my rush I forgot that python requires the return statements.
You people think I'm trying to push lisp, which I am not. (Apparently
many people do, because you are rather skittish.)
In S the value of the last executed statement of a function is the
returned value of the function by default, if there is no return() function.
It is very convenient for writing really small functions. But skip that for
now.
foo = function(x,y) { # S language
if (x>2) return(x+y*2)
x+y
}
foo = func(x,y): # My suggested python syntax (Improved!)
if x>2: return x+y*2
return x+y
# put the function object in the code wherever you want it.
bb= bar( a,b, func(x,y): x=x*2 ; b=4 ; return x*b+y )
It still is a statement language. The statement is an explicit
assignment using the "=" like most other assignments. "Def" and "lambda"
are silly. Assign names to function objects names the same way
you assign them to any other object. Call a duck a duck.
While I'm at it, classes are objects too. Assign names to them the
same way you assign names to _any_ other object: "="
MyClass= class(inhereted):
attributes
functions
whatever
x=MyClass() # an object of the above class.
> The Pythonic way to write "more complicated yet still comprehensible
> list comprehensions" is to not use list comprehensions.
>
> b = []
> for x in vec1:
> if x > 0:
> for y in vec2:
> if y > x:
> b.append(x + y)
>
You have just demonstrated that list comprehensions are not really
necessary at all. So given the "one clear way of doing things",
shouldn't they be removed? My point is that if you are going to
have them, why make some new unstructured syntax for them?
--
http://mail.python.org/mailman/listinfo/python-list
