will python 3000 break my code?

[bjorn]

Daniel Berlin wrote:

> >>>>> "bjorn" ==   <bjorn at roguewave.com> writes:
>
>    >> [snippage]
>    >> 3) it's considered Bad Style to use multi-argument append, IMHO.
>    >>  ahem.  does your HO really matter to all those who have to spend time
>    >> and money changing their existing code base.  preliminary results
>    >> indicate that *all* our applications and libraries (including PIL) are
>    >> affected by this change.  given that, it's quite likely that a few
>    >> other companies will also stumble upon this one...
>
>    bjorn> I must say I was kind of concerned when Guido announced this
>    bjorn> change.  Where I work, source code incompatible changes are an
>    bjorn> almost complete no-no, even for major releases.  The impact to
>    bjorn> customers is just too great.  The moral is probably, if you made an
>    bjorn> implementation boo-boo, you better learn to live with it quickly.
>
> Oh. I see. MS syndrome.
>
> This is the silliest thing i've ever heard.
> If your C++ compiler has an implementation bug, and accepts some code it
> shouldn't, then they shouldn't fix it because too many customers might depend
> on buggy code?
> Sorry, that's just not the way it works.
> This is a *BUG*. NOT A FEATURE.
> Why is this so hard to understand.
> You don't deprecate bugs.
> You fix them.
> Anyone who made a bug in their code, has to fix it.
> But they didn't know, you say?
> Now they know.
> When I worked at MS (MS Research, but I knew intimately what went on inside
> MS, obviously), there was way too much of this mentality of "We can't fix
> bugs because customers depend on them".
> They were right of course, that it would break programs.
> Mainly Idiot programmers (sorry, but i'm referring to the idiots specifically
> coding assuming a *BUG* would always exist. It's different to make a mistake,
> or check for a bug. But to simply assume no one will ever fix it is idiotic)
> would program assuming bugs would always be there.
> MS wouldn't fix the bug, because it would break too many programs.
> So they were damned either way.
> If they fixed it, it would break programs.
> If they left it, they get yelled at for not fixing bugs.
> So invariably, they left it.
> This isn't the right answer.
> The answer is to try to fix the bug as quickly as possible, so the least
> number of people have the chance to write buggy code.
> But if, later on, you find the bug, and it's existed for quite a while, that
> doesn't mean you don't fix it.
> If it was a feature, i might agree. It's not.
> It's a bug.
> Bugs don't get deprecated.
> I don't see g++ saying "Warning: Doing this will no longer work in the next
> version because you shouldn't have been doing this in the first place.".
> It says "ANSI C++ forbids ...".
> It's an error.

No, it's a design change by a standards committe, that has evaluated all the
options, giving individual vendors the chance to veto any changes that would be
too radical for their customers (I know, I've been there).  It's an enormous leap
from that to deciding that list.append(1,2,3) might be so confusing to some
newcomers that people who know what they were doing have to change their code
(ask Frederik if he doesn't have more interesting things to do than fixing
multiargument appends ;-)

> Unless you turn on a flag turning compliance errors into warnings.
> Most people will actually turn off the warning rather than fix the broken
> code.
>
> Does this break a lot of code?
> Sure.
> Should that code break?
> Yup.
>
> Should people stop fixing bugs in the python implementation cause some major
> customer has programmers who wrote buggy code?
> Nope.

Was this a bug?  Not really.  Was it a source incompatible design change? You
bet.

>    bjorn> I suppose I can agree with his analysis of the "evils" of
>    bjorn> multiargument append, but I'm not sure I think it's a big enough
>    bjorn> deal to break source compatibility.
>
> God damn it. It's not a feature. It's a bug. A bug. It should have been an
> error nit he first place. It's only by the grace of Guido and a slip of the
> eye that it wasn't.

And nobody would have complained if it _was_ an error in the first place.

>    | the-days-of-legacy-code-are-upon-us'ly y'rs
> No they aren't.

If you're going to have any luck getting a company (vs. individual dedicated
programmers) to use your tools, is if the tools are stable enough that a company
doesn't have to spend money every time you do a new release.  If you do think a
change is neccessary, and they often are although I'm not sure this particular
one rises to that level, you should at least warn customers by upping a major rev
number (or waiting until it's time to do so).

The-price-of-purity-is-obscurity'ly y'rs
-- bjorn

ps: since Guido hath spoken, there really is no reason to discuss this further,
so this'll have to be my last words on the issue -- I know we're all heartbroken
<wink>