will python 3000 break my code?

[Daniel Berlin]

> 
> 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 ;-)
Actually, it's not a design change in about 95% of the incompatible
changes in g++. It's just the implementation happened to be allowing
illegal (by the language standard) things because nobody had gotten around
to saying "that's illegal". It's not a world away from deciding that
something that was never legal in the first place, and was accepted, is
now 
not accepted.

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

Not a bug?
Can you point out where it says  in the documentation, that this is
allowed?
If you can point out where it says this was supposed to be allowed, i'll
happily agree that it's a source incompatible design change, and thus, is
a bad thing (TM).
 > 
> >
> > 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.
I'll give you that.
But sometimes things slip through.

> 
> >    | 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).
> 
I have companies that use my tools.
They are stable.
When people report bugs,I fix them.
I don't retroactively decide that things that were features are now bugs.
Which is what you seem to be trying to say is happening here.
Look. I'll hapilly agree that if that were the case, it'd be wrong to just
change it without warning.
That would be legacy code.
If it's not the case, then the cod eis not legacy code, it's buggy code.
Regardless of how long it worked for, it's still buggy.

> 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>
> 
> 
> -- 
> http://www.python.org/mailman/listinfo/python-list
>