[Python-3000] Backward compatibility

[Ian Bicking]

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org