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

Steve Howell showell30 at
Thu Feb 18 15:15:20 CET 2010

On Feb 18, 1:23 am, Duncan Booth < at invalid.invalid> wrote:
> Jonathan Gardner <jgard... at> 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>,
> >> 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

    def factory():
        return lambda: 15 / 0

    def bar(method):

    def foo(method):

    def baz(method):

        print 'problem with version 1.234a'

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

More information about the Python-list mailing list