[Python-Dev] Python 3 design principles

Oren Tirosh orent at hishome.net
Thu Sep 1 07:36:55 CEST 2005


On 9/1/05, Robert Kern <rkern at ucsd.edu> wrote:
> Oren Tirosh wrote:
> 
> > While a lot of existing code will break on 3.0 it is still generally
> > possible to write code that will run on both 2.x and 3.0: use only the
> > "proper" forms above, do not assume the result of zip or range is a
> > list, use absolute imports (and avoid static types, of course). I
> > already write all my new code this way.
> >
> > Is this "common subset" a happy coincidence or a design principle?
> 
> I think it's because those are the most obvious things right now. The
> really radical stuff won't come up until active development on Python
> 3000 actually starts. And it will, so any "common subset" will probably
> not be very large.

Static typing is radical stuff and doesn't hurt the common subset
since it's optional. Making unicode the default is pretty radical and
can be done without breaking the common subset (with the help of
little tweaks like allowing str() to return unicode now like int() can
return longs). Iterators and new-style classes were pretty radical
changes that were managed elegantly and meet an an even stronger
requirement than the common subset - they were achieved with full
backward compatibility.

Python 3 will most probably make big changes in the internal
implementation and the C API. Perhaps it will even be generated from
PyPy.

I don't think keeping the common subset will really stand in the way
of making big improvements. The proposed 3.x changes that break it
seem more like nitpicking to me than significant improvements.

Python is terrific. I find nothing I really want to change. Remove old
cruft and add some brand new stuff, yes. But nothing to change.

  Oren


More information about the Python-Dev mailing list