Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.

[Steve Howell]

On Feb 16, 4:19 pm, Jonathan Gardner <jgard... at jonathangardner.net>
wrote:
> On Feb 16, 11:41 am, Andrej Mitrovic <andrej.mitrov... at gmail.com>
> wrote:
>
>
>
> > On Feb 16, 7:38 pm, Casey Hawthorne <caseyhHAMMER_T... at 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)