On Feb 16, 4:19 pm, Jonathan Gardner <jgard...@jonathangardner.net> wrote: > On Feb 16, 11:41 am, Andrej Mitrovic <andrej.mitrov...@gmail.com> > wrote: > > > > > On Feb 16, 7:38 pm, Casey Hawthorne <caseyhhammer_t...@istar.ca> > > wrote: > > > > Interesting talk on Python vs. Ruby and how he would like Python to > > > have just a bit more syntactic flexibility. > > > >http://blog.extracheese.org/2010/02/python-vs-ruby-a-battle-to-the-de... > > > -- > > > Regards, > > > Casey > > > Gary's friend Geoffrey Grosenbach says in his blog post (which Gary > > linked to): "Python has no comparable equivalent to Ruby’s do end > > block. Python lambdas are limited to one line and can’t contain > > statements (for, if, def, etc.). Which leaves me wondering, what’s the > > point?" > > > I'm sorry, lambda's do support if's and for's. Also, lambda's are > > expressions, not statements, but you can pass them around, keep them > > in a dictionary if you want to. And if you need more than one line of > > statements, for crying out loud use a def? And who needs those "do- > > end" blocks anyway, trying to turn Python into Pascal? > > I used to think anonymous functions (AKA blocks, etc...) would be a > nice feature for Python. > > Then I looked at a stack trace from a different programming language > with lots of anonymous functions. (I believe it was perl.) > > I became enlightened.
I use Ruby a lot in my day job, and we rarely use blocks are as anonymous callback functions, which was probably the source of your pain in other languages. Often Ruby blocks are just three or four lines of code that are inlined into a still small function, so as long as the outer function is still small (which Ruby's blocks help with--they promote terseness), it's pretty easy to find a buggy function within a traceback that is not overly big. It's also possible in Ruby to use quality-promoting techniques like unit testing, pair programming, deliberateness, etc., to avoid the need for looking at tracebacks in the first place. Python is not immune to hard-to-understand tracebacks, since you often don't often know how a method got itself into the stracktrace in the first place: Traceback (most recent call last): File "foo.py", line 11, in <module> foo(method) File "foo.py", line 2, in foo method() File "foo.py", line 5, in bar raise Exception('I am broken!') Exception: I am broken! Even though there's no direct lexical reference to bar() in foo(), lo and behold, foo() ends up calling bar(): def foo(method): method() def bar(): raise Exception('I am broken!') def broken_function_factory(): return bar method = broken_function_factory() foo(method) -- http://mail.python.org/mailman/listinfo/python-list