Interesting talk on Python vs. Ruby and how he would like Python to have just a bit more syntactic flexibility.
steve at holdenweb.com
Fri Feb 19 04:48:21 CET 2010
Steven D'Aprano wrote:
> On Thu, 18 Feb 2010 06:15:20 -0800, Steve Howell wrote:
> 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
> shooting down.
> 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.
> Strawman #4.
> 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
Next week: Lesson 2 - Ad Hominem Attacks
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/
More information about the Python-list