[Python-Dev] Python 3 design principles

James Y Knight foom at fuhm.net
Wed Aug 31 23:39:54 CEST 2005

On Aug 31, 2005, at 5:00 PM, Robert Kern wrote:
> IMO, if we are going to restrict Python 3000 enough to protect that
> "common subset," then there's not enough payoff to justify breaking
> *any* backwards compatibility. If my current codebase[1] isn't  
> going to
> be supported in Python 3000, I'm going to want the Python  
> developers to
> use that opportunity to the fullest advantage to make a better  
> language.

I disagree fully. As a maintainer in the Twisted project I very much  
hope that it is possible to adapt the code such that it will work on  
Python 3 while still maintaining compatibility with Python 2.X.  
Otherwise, it will be impossible to make the transition to Python 3  
without either maintaining two forks of the codebase (I doubt that'll  
happen) or abandoning all users still on Python 2. And that surely  
won't happen either, for a while. Maybe by the time Python 3.1 or 3.2  
comes out it'll be possible to completely abandon Python 2.

I'm perfectly happy to see backwards-incompatible changes in Python  
3, as long as they do not make it completely impossible to write code  
that can run on both Python 3 and Python 2.X. This suggests a few  
things to me:

a) new features should be added to the python 2.x series first  
wherever possible.
b) 3.0 should by and large by simply a feature-removal release,  
removing support for features already marked as going away by the end  
of the 2.x series and which have replacements.
c) don't make any radical syntax changes which make it impossible to  
write code that can even parse in both versions.
d) for all backwards-incompatible-change proposals, have a section  
dedicated to compatibility and migration of old code that explains  
both how to modify old code to do things purely the new way, _and_  
how to modify code to work under both the old and new ways. Strive to  
make this as simple as possible, but if totally necessary, it may be  
reasonable to suggest writing a wrapper function which changes  
behavior based on python version/existence of new methods.


More information about the Python-Dev mailing list