On 3/23/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > >>I saw this too in the archives, and thought shit, that's going to mess > >>up a lot of my code. I would assume (though it's a separate point of > >>discussion) that Python 3k should still try hard to keep backward > >>compatibility. Backward compatibility isn't a requirement, but it's > >>still clearly a feature. > > > > > > You seem to be misunderstanding what Python 3000 is. The whole point > > of Python 3000 is to *not* be bound by backwards compatibility > > constraints, but instead make the best decisions possible (without > > making it a different language). > > I think this was in the bullet points of pending discussions, so maybe > should be a separate thread. > > When I say it is a feature... I guess that seems obvious to me. In 2.x > backward compatibility is something of a requirement. But in 3.0/3000 > backward compatibility is still a nice thing to have, that can be > weighed against other nice things. That doesn't seem overly > constrained, just practical. >
I don't think things are going to be broken gratuitously. Just look at the backlash against PEP 348. The most common reason for not wanting a change was not because a suggestion was bad, just that the benefit of the change was outweighed by the breakage and pain of transition. I suspect all changes will be weighed this way and thus extreme breakage will be done only in cases where a clear benefit exists. Plus we will have to all convert stdlib code over so we will have a decent idea of what is needed in terms of guidellines or tools to make the transition easier. -Brett _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
