Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.
steve at REMOVE-THIS-cybersource.com.au
Thu Feb 18 23:17:57 CET 2010
On Thu, 18 Feb 2010 06:15:20 -0800, Steve Howell wrote:
> 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.
>> 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.
There really ought to be a special level of Hell for people who misuse
"strawman" to mean "a weak or invalid argument" instead of what it
actually means, which is a weak or invalid argument NOT HELD by your
opponent, which you (generic you) made up specifically for the sake of
If you actually read what Duncan says, he prefixes his response with:
"Some problems with using just line numbers to track errors".
Duncan's post is an argument against relying on line numbers as your
main, or only, source of information about the location of bugs in
In fact, this post is remarkable for the sheer number of actual strawman
arguments that you (Steve Howell) use:
> Shipping buggy code is a bad idea, even with named functions.
Strawman #1: nobody said that shipping buggy code was a good idea, with
or without named functions. But shipping buggy code *happens*, no matter
how careful you are, so you need to expect bug reports back from users.
(And they will be *hard to find* bugs, because if they were easy to find
you would have found them in your own testing before shipping.)
> Obscuring line numbers is a bad idea, even with named functions.
Strawman #2: nobody said that obscuring line numbers was a good idea. But
obscuring the line numbers is the side-effect of doing so.
And even knowing the line numbers is not necessarily useful, because many
bugs aren't due to the line that raises the stack trace. Just because you
know the line which failed doesn't mean you know how to fix the bug.
> Having your customers stay on older versions of your software is a bad
> idea, even with named functions.
Strawman #3: nobody said that staying on older versions is a good idea.
But sometimes it happens whether you like it or not.
(Although I'd like to point out that from the end user's perspective,
sometimes we don't want your stinkin' new version with all the anti-
features and pessimations and will stick to the old version for as long
as possible. If you don't like it, then think a bit harder before adding
anti-features like fragile, easily-corrupted databases which perform
really, really badly when your home directory is mounted over the
network. I'm talking to you, Firefox developers.)
And it doesn't really matter: you either end-of-life the old version, in
which case you don't need to do anything about the bug report except say
"upgrade", or you decide to continue support, in which case it doesn't
matter whether the bug is reported for an old version or the latest
version, you still need to fix it.
> Not being able to know which version of software you're customer is
> running is a bad idea, even with named functions.
See the pattern? When you attack a position the other guy hasn't taken,
that's a strawman. When you make a weak argument, it's just a weak
More information about the Python-list