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

[Steve Howell]

On Feb 18, 1:23 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
> Jonathan Gardner <jgard... at jonathangardner.net> wrote:
> > On Feb 17, 12:02 am, Lawrence D'Oliveiro <l... at geek-
> > central.gen.new_zealand> wrote:
> >> In message
> >> <8ca440b2-6094-4b35-80c5-81d000517... at v20g2000prb.googlegroups.com>,
>
> >> Jonathan Gardner wrote:
> >> > 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.)
>
> >> Didn’t it have source line numbers in it?
>
> >> What more do you need?
>
> > I don't know, but I tend to find the name of the function I called to
> > be useful. It's much more memorable than line numbers, particularly
> > when line numbers keep changing.
>
> > I doubt it's just me, though.
>
> Some problems with using just line numbers to track errors:
>
> In any language it isn't much use if you get a bug report from a shipped
> program that says there was an error on line 793 but no report of
> exactly which version of the shipped code was being run.
>
> Microsoft love telling you the line number: if IE gets a Javascript
> error it reports line number but not filename, so you have to guess
> which of the HTML page or one of many included files actually had the
> error. Plus the line number that is reported is often slightly off.
>
> Javascript in particular is often sent to the browser compressed then
> uncompressed and eval'd. That makes line numbers completely useless for
> tracking down bugs as you'll always get the line number of the eval.
> Also the way functions are defined in Javascript means you'll often have
> almost every function listed in a backtrace as 'Anonymous'.

If this is an argument against using anonymous functions, then it is a
quadruple strawman.

Shipping buggy code is a bad idea, even with named functions.

Obscuring line numbers is a bad idea, even with named functions.

Having your customers stay on older versions of your software is a bad
idea, even with named functions.

Not being able to know which version of software you're customer is
running is a bad idea, even with named functions.

Of course, using anonymous functions in no way prevents you from
capturing a version number in a traceback.  And in most modern source
control systems, it is fairly easy to revert to an old version of that
code.

    def factory():
        return lambda: 15 / 0

    def bar(method):
        method()

    def foo(method):
        bar(method)

    def baz(method):
        foo(method)

    try:
        baz(factory())
    except:
        print 'problem with version 1.234a'
        raise

    problem with version 1.234a
    Traceback (most recent call last):
      File "foo.py", line 14, in <module>
        baz(factory())
      File "foo.py", line 11, in baz
        foo(method)
      File "foo.py", line 8, in foo
        bar(method)
      File "foo.py", line 5, in bar
        method()
      File "foo.py", line 2, in <lambda>
        return lambda: 15 / 0
    ZeroDivisionError: integer division or modulo by zero