Movatterモバイル変換


[0]ホーム

URL:


[Python-Dev] Python 3 design principles

Oren Tiroshoren.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 beone 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 !=, repretc.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 generallypossible 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 alist, use absolute imports (and avoid static types, of course). Ialready 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 newthings. Some of them just change the way certain things must be done.For example:*  Moving compile, id, intern to sys*  Replacing print with write/writelnAnd possibly the biggest change:*  Reorganize the standard library to not be as shallowI'm between +0 and -1 on these. I don't find them enough of animprovement to break this "common subset" behavior. It's not quite thesame as strict backward compatibility and I find it worthwhile to tryto keep it.Writing programs that run on both 2.x and 3 may require uglyversion-dependent tricks like:try:    compileexcept NameError:    from sys import compileor perhapstry:    import urllibexcept ImportError:    from www import urllibShould the "common subset" be a design principle of Python 3? Docompile and id really have to be moved from __builtins__ to sys? Couldthe rearrangement of the standard library be a bit less aggressive andtry to leave commonly used modules in place?  Oren


More information about the Python-Devmailing list

[8]ページ先頭

©2009-2025 Movatter.jp