Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.
showell30 at yahoo.com
Thu Feb 18 15:15:20 CET 2010
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.
> 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.
> 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.
> almost every function listed in a backtrace as 'Anonymous'.
If this is an argument against using anonymous functions, then it is a
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
return lambda: 15 / 0
print 'problem with version 1.234a'
problem with version 1.234a
Traceback (most recent call last):
File "foo.py", line 14, in <module>
File "foo.py", line 11, in baz
File "foo.py", line 8, in foo
File "foo.py", line 5, in bar
File "foo.py", line 2, in <lambda>
return lambda: 15 / 0
ZeroDivisionError: integer division or modulo by zero
More information about the Python-list