will python 3000 break my code?

[Daniel Berlin]

>>>>> "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.
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.

   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.  

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

   | -- bjorn

   | -- 
   | http://www.python.org/mailman/listinfo/python-list