The business case here is that languages which cannot keep b/w compatibility at reasonable level should not be used for any future projects... Existing projects are either to be mothballed or rewritten in another language..
Such breakage is tolerable for a language which is just starting. It's a suicidal mistake for a language with massive deployed code base.
Two more observations.
A. it's not a binary choice, breaking changes could have been introduced with deprecations/future imports/etc which would have been slower (but then it might still be faster than what we've got with python3 ;-)
B. given that the cost of b/w compatibility breakage is so high, it only should be broken for clear improvements. Python 3 does not meet this requirement IMHO:
B1. print function vs print statement. A wash.
B2. unicode by default. A mess. (as in: it has broken about as many things as it has fixed)
B3. dictionary interface changes. (.keys() is now an iterator). A minor improvement
0
u/[deleted] May 26 '14
[deleted]