Frank Samuelson a écrit :
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.
Did I mention Lisp ??? No need to go lispish for this - Javascript
already does what you want here. FWIW, I was somewhat thinking out loud,
and I guess I thought of Javascript's use of anonymous functions, then
switched to Ruby (and it's code blocks), which took me to
expression-based languages. That's all.
(Apparently
many people do, because you are rather skittish.)
I don't get the point here.
In S the value of the last executed statement of a function is the
returned value of the function by default,
Which is what expression-based languages usually do - cf Ruby and most
functional languages.
if there is no return()
function.
Actually, in most languages, it's a statement !-)
It is very convenient for writing really small functions.
For really small functions, Python has lambda - which actually work that
way.
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 )
bb = bar(a, b, func(x,y):
for x in y:
if x > 10:
do_something_with(x)
return y[-1] * 42
ho, wait, I have a couple keyword args to pass to bar too... How should
I do ? add a comma after the return statement ???
Franck, believe us, *this has been beaten to hell and back*. The point
is not that full anonymous functions are a bad thing (I personally use
them a lot in Javascript), but that it just doesn't fit within Python,
and that the necessary modifications would yield a mostly different
language. Perhaps a pretty good one, but not Python anymore. You see, I
don't necessarily share all Python's design choices, and I'm well aware
of some restrictions they impose. But day in, day out, it happens that
these choices are mostly coherent, and that the resulting language
offers a (IMHO) great balance between simplicity and power.
Non-programmers can (and do) use it, C programmers can (and do) use it,
Java programmers can (and do) use it, Lisp programmers can (and do) use
it, etc, etc, etc.
While I'm at it, classes are objects too. Assign names to them the
same way you assign names to _any_ other object: "="
Same problem. Note that in both cases, you already *can* build functions
and classes that way - as you say, they are objects, and both the def
and class statements are somewhat syntactic sugar. The only point is
that, to instanciate a function, you have more to do:
Help on class function in module __builtin__:
class function(object)
| function(code, globals[, name[, argdefs[, closure]]])
|
| Create a function object from a code object and a dictionary.
| The optional name string overrides the name from the code object.
| The optional argdefs tuple specifies the default argument values.
| The optional closure tuple supplies the bindings for free variables
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",
Actually, it's: "there should be one - and preferably only one - obvious
way to do it". List comps are the obvious way for simple list
operations, and for loops are the obvious way for complex operations. If
you're in for Python Zen quotes, here are some others:
"""
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
"""
shouldn't they be removed? My point is that if you are going to
have them, why make some new unstructured syntax for them?
Because there's already a (well-known) structured syntax for the cases
that are too complex to fit a single, simple expression. It's a question
of balance between purity, readability, and practicallity.
