[Python-Dev] Python 3 design principles

Oren Tirosh oren.tirosh at gmail.com
Wed Aug 31 22:24:52 CEST 2005


Most of the changes in PEP 3000 are tightening up of  "There should be
one obvious way to do it.":
* Remove multiple forms of raising exceptions, leaving just "raise instance" 
* Remove exec as statement, leaving the compatible tuple/call form.
* Remove <>, ``, leaving !=, repr
etc.

Other changes are to disallow things already considered poor style like:
* No assignment to True/False/None 
* No input() 
* No access to list comprehension variable 

And there is also completely new stuff like static type checking.

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? 

Not all proposed changes remove redundancy or add completely new
things. Some of them just change the way certain things must be done.
For example:
*  Moving compile, id, intern to sys
*  Replacing print with write/writeln
And possibly the biggest change:
*  Reorganize the standard library to not be as shallow

I'm between +0 and -1 on these. I don't find them enough of an
improvement to break this "common subset" behavior. It's not quite the
same as strict backward compatibility and I find it worthwhile to try
to keep it.

Writing programs that run on both 2.x and 3 may require ugly
version-dependent tricks like:

try:
    compile
except NameError:
    from sys import compile

or perhaps

try:
    import urllib
except ImportError:
    from www import urllib

Should the "common subset" be a design principle of Python 3? Do
compile and id really have to be moved from __builtins__ to sys? Could
the rearrangement of the standard library be a bit less aggressive and
try to leave commonly used modules in place?

  Oren


More information about the Python-Dev mailing list