[Python-Dev] Python 3 design principles
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
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.
* 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:
from sys import compile
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?
More information about the Python-Dev