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. As someone who wants to use new features, but also wants to do useful work collaboratively with other people who may not care about nice features, the upgrade path is really important to me. That there's some working subset for both 2.x and 3.0 is *really* important. That code doesn't break in weird or hard ways is also really important. Easy ways isn't that big a deal -- a few AttributeErrors, or even better a suggestive NotImplementedError. Better yet SyntaxError. And maybe if d.keys().append() just fails, that'll be okay. That's probably an argument against clever implementations, really -- better to get an exception sooner than later. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
