PEP: 3100 Title: Miscellaneous Python 3.0 Plans Version: $Revision$ Last-Modified: $Date$ Author: A.M. Kuchling , Brett Cannon Status: Draft Type: Informational Content-Type: text/x-rst Created: 20-Aug-2004 Post-History: Abstract ======== This PEP, previously known as PEP 3000, describes smaller scale changes and new features for which no separate PEP is written yet, all targeted for Python 3000. The list of features included in this document is subject to change and isn't binding on the Python development community; features may be added, removed, and modified at any time. The purpose of this list is to focus our language development effort on changes that are steps to 3.0, and to encourage people to invent ways to smooth the transition. This document is not a wish-list that anyone can extend. While there are two authors of this PEP, we're just supplying the text; the decisions for which changes are listed in this document are made by Guido van Rossum, who has chosen them as goals for Python 3.0. Guido's pronouncements on things that will not change in Python 3.0 are recorded in PEP 3099. [#pep3099]_ General goals ============= A general goal is to reduce feature duplication by removing old ways of doing things. A general principle of the design will be that one obvious way of doing something is enough. [1]_ Influencing PEPs ================ * PEP 238 (Changing the Division Operator) [#pep238]_ * PEP 328 (Imports: Multi-Line and Absolute/Relative) [#pep328]_ * PEP 343 (The "with" Statement) [#pep343]_ * PEP 352 (Required Superclass for Exceptions) [#pep352]_ Style changes ============= * The C style guide will be updated to use 4-space indents, never tabs. This style should be used for all new files; existing files can be updated only if there is no hope to ever merge a particular file from the Python 2 HEAD. Within a file, the indentation style should be consistent. No other style guide changes are planned ATM. Core language ============= * True division becomes default behavior [#pep238]_ [done] * ``exec`` as a statement is not worth it -- make it a function [done] * (Maybe) add optional declarations for static typing [11]_ * Support only new-style classes; classic classes will be gone [1]_ [done] * Replace ``print`` by a function [16]_ * Use ``except E1, E2, E3 as err:`` if you want the error variable. [3]_ * ``None`` becomes a keyword [4]_ (What about ``True``, ``False``?) * ``...`` to become a general expression element [24]_ [done] * ``as`` becomes a keyword [5]_ (starting in 2.6 already) [done] * Have list comprehensions be syntactic sugar for passing an equivalent generator expression to ``list()``; as a consequence the loop variable will no longer be exposed [12]_ * Comparisons other than ``==`` and ``!=`` between disparate types will raise an exception unless explicitly supported by the type [6]_ [done] * Exceptions might grow an attribute to store the traceback [13]_ * floats will not be acceptable as arguments in place of ints for operations where floats are inadvertantly accepted (PyArg_ParseTuple() i & l formats) * Imports will be absolute by default. [done] Relative imports must be explicitly specified [#pep328]_ [done] * __init__.py might become optional in sub-packages. __init__.py will still be required for top-level packages. * Cleanup the Py_InitModule() variants {,3,4} (also import and parser APIs) * Cleanup the APIs exported in pythonrun, etc. * Some expressions will require parentheses that didn't in 2.x: - List comprehensions will require parentheses around the iterables. This will make list comprehensions more similar to generator comprehensions. [x for x in 1, 2] will need to be: [x for x in (1, 2)] - Lambdas may have to be parenthesized [23]_ * Builtin module init function names (PyMODINIT_FUNC) will be prefixed with _Py (or Py). Currently they aren't namespace safe since the names start with init. * __builtins__ should get a different name *or* completely unified with __builtin__. Keeping both with confusingly similar spellings and semantics is evil. * Attributes on functions of the form ``func_whatever`` will be renamed ``__whatever__`` [25]_ * Set literals and comprehensions [27]_ [28]_ [done] {x} means set([x]); {x, y} means set([x, y]). {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)). NB. {range(x)} means set([range(x)]), NOT set(range(x)). There's no literal for an empty set; use set() (or {1}&{2} :-). There's no frozenset literal; they are too rarely needed. * Might reconsider PEP 299 [30]_: special __main__() function in modules. To be removed: * String exceptions: use instances of an Exception class [2]_ [done] * ``raise Exception, "message"``: use ``raise Exception("message")`` [14]_ * ```x```: use ``repr(x)`` [2]_ [done] * The ``<>`` operator: use ``!=`` instead [3]_ [done] * The __mod__ and __divmod__ special methods on float. [29]_ * Might drop unbound methods? [7]_ * METH_OLDARGS * WITH_CYCLE_GC [done] * __getslice__, __setslice__, __delslice__ [17]_; remove slice opcodes and use slice objects. [Thomas Wouters is working on this in a branch] * C APIs (see code): PyFloat_AsString, PyFloat_AsReprString, PyFloat_AsStringEx, PySequence_In, PyEval_EvalFrame, PyEval_CallObject, _PyObject_Del, _PyObject_GC_Del, _PyObject_GC_Track, _PyObject_GC_UnTrack PyString_AsEncodedString, PyString_AsDecodedString PyArg_NoArgs, PyArg_GetInt, intargfunc, intintargfunc Atomic Types ============ * Remove distinction between int and long types [1]_ (int may become an abstract base type, with short and long subtypes.) [MvL is working on this in the int_unification branch] * Make all strings be Unicode, and have a separate bytes() type [1]_ The new string type will be called 'str'. * Return iterators instead of lists where appropriate for atomic type methods (e.g. ``dict.keys()``, ``dict.values()``, ``dict.items()``, etc.); iter* methods will be removed. Better: make keys(), etc. return views ala Java collections??? * Make ``string.join()`` stringify its arguments? [26]_ To be removed: * ``basestring.find()`` and ``basestring.rfind()``; use ``basestring.index()`` or ``basestring.[r]partition()`` or or ``basestring.rindex()`` in a try/except block??? [15]_ * ``file.xreadlines()`` method [#file-object]_ [done] * ``dict.setdefault()``? [22]_ * ``dict.has_key()`` method [done] Built-in Namespace ================== * Make built-ins return an iterator where appropriate (e.g. ``range()``, ``zip()``, etc.) [zip is done; Neal Norwitz has a patch for range()] * Relevant functions should consume iterators (e.g. ``min()``, ``max()``) [They already do, since 2.2.] * Introduce ``trunc()``, which would call the ``__trunc__()`` method on its argument; suggested use is for objects like float where calling ``__int__()`` has data loss, but an integral representation is still desired? [8]_ * Exception hierarchy changes [#pep352]_ [done] To be removed: * ``apply()``: use ``f(*args, **kw)`` instead [2]_ [done] * ``buffer()``: must die (use a bytes() type instead) (?) [2]_ * ``callable()``: just call the object and catch the exception [2]_ * ``compile()``: put in ``sys`` (or perhaps in a module of its own) [2]_ * ``coerce()``: no longer needed [2]_ * ``execfile()``, ``reload()``: use ``exec()`` [2]_ * ``input()``: use ``eval(sys.stdin.readline())`` [2]_ [done] * ``intern()``, ``id()``: put in ``sys`` [2]_ * ``map()``, ``filter()``: use list comprehensions instead??? [1]_, [9]_ (Actually these can stay.) * ``reduce()``: write a loop instead [2]_, [9]_ [done] * ``raw_input()``: use ``sys.stdin.readline()`` ??? [2]_ [done] * ``xrange()``: use ``range()`` instead [1]_ [See range() above] Standard library ================ * Reorganize the standard library to not be as shallow? * Move test code to where it belongs, there will be no more test() functions in the standard library * Convert all tests to use either doctest or unittest. * For the procedures of standard library improvement, see PEP 3001 [#pep3001]_ To be removed: * stdlib modules to be removed + see docstrings and comments in the source - ``macfs``, ``new``, ``reconvert``, ``stringold``, ``xmllib``, ``pcre``, ``pypcre``, ``strop`` + see PEP 4 [18]_ - ``posixfile``, ``pre``, ``regsub``, ``rfc822``, ``statcache``, ``string``, ``TERMIOS`` ``mimetools``, ``MimeWriter``, ``mimify``, ``mpz``, ``rgbimage`` + Everything in lib-old [18]_ - ``Para``, ``addpack``, ``cmp``, ``cmpcache``, ``codehack``, ``dircmp``, ``dump``, ``find``, ``fmt``, ``grep``, ``lockfile``, ``newdir``, ``ni``, ``packmail``, ``poly``, ``rand``, ``statcache``, ``tb``, ``tzparse``, ``util``, ``whatsound``, ``whrandom``, ``zmod`` * ``sys.exitfunc``: use atexit module instead [#sys-module]_ * ``sys.exc_type``, ``sys.exc_values``, ``sys.exc_traceback``: not thread-safe; use ``sys.exc_info()`` or an attribute of the exception [2]_ [13]_ [#sys-module]_ * ``array.read``, ``array.write`` [#array-module]_ * ``operator.isCallable`` : ``callable()`` built-in is being removed [#operator-module]_ * ``operator.sequenceIncludes`` : redundant thanks to ``operator.contains`` [#operator-module]_ * In the thread module, the aquire_lock() and release_lock() aliases for the acquire() and release() methods on lock objects. (Probably also just remove the thread module as a public API, in favor of always using threading.py.) * UserXyz classes, in favour of XyzMixins. Outstanding Issues ================== * Require C99, so we can use // comments, named initializers, declare variables without introducing a new scope, among other benefits. (Also better support for IEEE floating point issues like NaN and infinities?) * Remove support for old systems, including: BeOS, RISCOS, (SGI) Irix, Tru64 References ========== .. [1] PyCon 2003 State of the Union: http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt .. [2] Python Regrets: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf .. [9] Guido's blog ("The fate of reduce() in Python 3000") http://www.artima.com/weblogs/viewpost.jsp?thread=98196 .. [11] Guido's blog ("Python Optional Typechecking Redux") http://www.artima.com/weblogs/viewpost.jsp?thread=89161 .. [3] Python Wiki: http://www.python.org/moin/Python3.0 .. [4] python-dev email ("Constancy of None") http://mail.python.org/pipermail/python-dev/2004-July/046294.html .. [5] python-dev email (' "as" to be a keyword?') http://mail.python.org/pipermail/python-dev/2004-July/046316.html .. [6] python-dev email ("Comparing heterogeneous types") http://mail.python.org/pipermail/python-dev/2004-June/045111.html .. [7] python-dev email ("Let's get rid of unbound methods") http://mail.python.org/pipermail/python-dev/2005-January/050625.html .. [8] python-dev email ("Fixing _PyEval_SliceIndex so that integer-like objects can be used") http://mail.python.org/pipermail/python-dev/2005-February/051674.html .. [13] python-dev email ("anonymous blocks") http://mail.python.org/pipermail/python-dev/2005-April/053060.html .. [14] python-dev email ("PEP 8: exception style") http://mail.python.org/pipermail/python-dev/2005-August/055190.html .. [15] python-dev email (Remove str.find in 3.0?) http://mail.python.org/pipermail/python-dev/2005-August/055705.html .. [16] python-dev email (Replacement for print in Python 3.0) http://mail.python.org/pipermail/python-dev/2005-September/056154.html .. [21] python-dev email http://mail.python.org/pipermail/python-dev/2006-February/061169.html .. [22] python-dev email ("defaultdict") http://mail.python.org/pipermail/python-dev/2006-February/061261.html .. [24] python-3000 email http://mail.python.org/pipermail/python-3000/2006-April/000996.html .. [25] python-3000 email ("Pronouncement on parameter lists") http://mail.python.org/pipermail/python-3000/2006-April/001175.html .. [26] python-3000 email ("More wishful thinking") http://mail.python.org/pipermail/python-3000/2006-April/000810.html .. [27] python-3000 email ("sets in P3K?") http://mail.python.org/pipermail/python-3000/2006-April/001286.html .. [28] python-3000 email ("sets in P3K?") http://mail.python.org/pipermail/python-3000/2006-May/001666.html .. [29] python-3000 email ("bug in modulus?") http://mail.python.org/pipermail/python-3000/2006-May/001735.html .. [17] Python docs (Additional methods for emulation of sequence types) http://docs.python.org/ref/sequence-methods.html .. [#sys-module] Python docs (sys -- System-specific parameters and functions) http://docs.python.org/lib/module-sys.html .. [#operator-module] Python docs (operator -- Standard operators as functions) http://docs.python.org/lib/module-operator.html .. [#array-module] Python docs (array -- Efficient arrays of numeric values) http://docs.python.org/lib/module-array.html .. [#file-object] Python docs (File objects) http://docs.python.org/lib/bltin-file-objects.html .. [18] PEP 4 ("Deprecation of Standard Modules") http://www.python.org/dev/peps/pep-0004 .. [#pep238] PEP 238 (Changing the Division Operator) http://www.python.org/dev/peps/pep-0238 .. [12] PEP 289 ("Generator Expressions") http://www.python.org/dev/peps/pep-0289 .. [30] PEP 299 ("Special __main__() function in modules") http://www.python.org/dev/peps/pep-0299 .. [23] PEP 308 ("Conditional Expressions") http://www.python.org/dev/peps/pep-0308 .. [#pep328] PEP 328 (Imports: Multi-Line and Absolute/Relative) http://www.python.org/dev/peps/pep-0328 .. [#pep343] PEP 343 (The "with" Statement) http://www.python.org/dev/peps/pep-0343 .. [#pep352] PEP 352 (Required Superclass for Exceptions) http://www.python.org/dev/peps/pep-0352 .. [#pep3001] PEP 3001 (Process for reviewing and improving standard library modules) http://www.python.org/dev/peps/pep-3001 .. [#pep3099] PEP 3099 (Things that will Not Change in Python 3000) http://www.python.org/dev/peps/pep-3099 Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: