Frank Samuelson a écrit : > 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.
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. -- http://mail.python.org/mailman/listinfo/python-list