iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
python-peps/pep-3100.txt

320 lines
12 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

PEP: 3100
Title: Miscellaneous Python 3.0 Plans
Version: $Revision$
Last-Modified: $Date$
Author: A.M. Kuchling <amk@amk.ca>,
Brett Cannon <drifty@alum.berkeley.edu>
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]_
Core language
=============
* True division becomes default behavior [10]_
* ``exec`` as a statement is not worth it -- make it a function
* Add optional declarations for static typing [11]_
* Support only new-style classes; classic classes will be gone [1]_
* Replace ``print`` by a function [16]_
* Do something so you can catch multiple exceptions using ``except E1,
E2, E3:``. Maybe use ``except E1, E2, E3 as err:`` if you want the
error variable? [3]_
* ``None``, ``True`` and ``False`` become keywords [4]_
(Or perhaps just ``None``?)
* ``as`` becomes a keyword [5]_ (probably in 2.6 already)
* 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]_
* Exceptions will 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.
Relative imports must be explicitly specified [19]_
* __init__.py will be 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 will 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.
To be removed:
* String exceptions: use instances of an Exception class [2]_
* ``raise Exception, "message"``: use ``raise Exception("message")`` [14]_
* ```x```: use ``repr(x)`` [2]_
* The ``<>`` operator: use ``!=`` instead [3]_
* Unbound methods [7]_
* METH_OLDARGS, WITH_CYCLE_GC
* __getslice__, __setslice__, __delslice__ [17]_
* Remove slice opcodes and use slice objects
* 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.)
* Make all strings be Unicode, and have a separate bytes() type [1]_
* 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
OR make keys(), etc. return views ala Java collections???
To be removed:
* ``basestring.find()`` and ``basestring.rfind()``; use ``basestring.index()``
or ``basestring.rindex()`` in a try/except block [15]_
* ``file.xreadlines()`` method [17]_
* ``dict.setdefault()`` [22]_
* ``dict.has_key()`` method
Built-in Namespace
==================
* Make built-ins return an iterator where appropriate (e.g. ``range()``,
``zip()``, etc.)
* Relevant functions should consume iterators (e.g. ``min()``,
``max()``)
* 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 [20]_
To be removed:
* ``apply()``: use ``f(*args, **kw)`` instead [2]_
* ``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]_
* ``intern()``, ``id()``: put in ``sys`` [2]_
* ``map()``, ``filter()``: use list comprehensions instead [1]_, [9]_
* ``reduce()``: write a loop instead [2]_, [9]_
* ``raw_input()``: use ``sys.stdin.readline()`` [2]_
* ``xrange()``: use ``range()`` instead [1]_
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
* For the procedures of standard library improvement, see PEP 3001 [#pep3001]_
To be removed:
* Deprecated modules, methods, parameters, attributes, etc. [1]_ [17]_ [18]_
There may be other modules, the most common are listed below.
stdlib modules to be removed (see docstrings and comments in the source):
* ``macfs``, ``new``, ``reconvert``, ``stringold``, ``xmllib``
* ``pcre``, ``pypcre``, ``strop``
stdlib modules to be removed (see PEP 4): [18]_
* ``posixfile``, ``pre``, ``regsub``, ``rfc822``,
* ``statcache``, ``string``, ``TERMIOS``
* ``mimetools``, ``MimeWriter``, ``mimify``,
* ``mpz``, ``rgbimage``
* Everything in lib-old: [18]_
* Para.py, addpack.py, cmp.py, cmpcache.py, codehack.py,
* dircmp.py, dump.py, find.py, fmt.py, grep.py, lockfile.py,
* newdir.py, ni.py, packmail.py, poly.py, rand.py, statcache.py,
* tb.py, tzparse.py, util.py, whatsound.py, whrandom.py, zmod.py
* ``sys.exitfunc``: use atexit module instead [17]_
* ``sys.exc_type``, ``sys.exc_values``, ``sys.exc_traceback``:
not thread-safe; use ``sys.exc_info()`` or an attribute
of the exception [2]_ [13]_ [17]_
* ``array.read``, ``array.write`` [17]_
* ``operator.isCallable``, ``operator.sequenceIncludes`` [17]_
* 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.
* 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
.. [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
.. [9] Guido's blog ("The fate of reduce() in Python 3000")
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
.. [10] PEP 238 ("Changing the Division Operator")
http://www.python.org/dev/peps/pep-0238
.. [11] Guido's blog ("Python Optional Typechecking Redux")
http://www.artima.com/weblogs/viewpost.jsp?thread=89161
.. [12] PEP 289 ("Generator Expressions")
http://www.python.org/dev/peps/pep-0289
.. [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
.. [17] Python docs
http://docs.python.org/ref/sequence-methods.html
http://docs.python.org/lib/module-sys.html
http://docs.python.org/lib/module-operator.html
http://docs.python.org/lib/module-array.html
http://docs.python.org/lib/bltin-file-objects.html
.. [18] PEP 4 ("Deprecation of Standard Modules")
http://www.python.org/dev/peps/pep-0004
.. [19] PEP 328 ("Imports: Multi-Line and Absolute/Relative")
http://www.python.org/dev/peps/pep-0328
.. [20] PEP 352 ("Required Superclass for Exceptions")
http://www.python.org/dev/peps/pep-0352
.. [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
.. [23] PEP 308 ("Conditional Expressions")
http://www.python.org/dev/peps/pep-0308
.. [#pep238] PEP 238 (Changing the Division Operator)
http://www.python.org/dev/peps/pep-0238
.. [#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:
Reference in New Issue View Git Blame Copy Permalink