On Feb 18, 1:23 am, Duncan Booth <duncan.bo...@invalid.invalid> wrote:
> Jonathan Gardner <jgard...@jonathangardner.net> wrote:
> > On Feb 17, 12:02 am, Lawrence D'Oliveiro <l...@geek-
> > central.gen.new_zealand> wrote:
> >> In message
> >> <8ca440b2-6094-4b35-80c5-81d000517...@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
--
http://mail.python.org/mailman/listinfo/python-list
