Update status of various items.

This commit is contained in:
Guido van Rossum 2006-09-06 06:42:42 +00:00
parent 6ac49a04dd
commit 1b26c9f57e
1 changed files with 17 additions and 13 deletions

View File

@ -64,19 +64,19 @@ Core language
=============
* True division becomes default behavior [#pep238]_ [done]
* ``exec`` as a statement is not worth it -- make it a function
* ``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]_
* ``as`` becomes a keyword [5]_ (probably in 2.6 already) [done]
* ``...`` 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]_
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)
@ -91,7 +91,7 @@ Core language
- 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]_
- 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
@ -101,7 +101,7 @@ Core language
and semantics is evil.
* Attributes on functions of the form ``func_whatever`` will be renamed
``__whatever__`` [25]_
* Set literals and comprehensions [27]_ [28]_
* 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)).
@ -119,8 +119,9 @@ To be removed:
* Might drop unbound methods? [7]_
* METH_OLDARGS
* WITH_CYCLE_GC [done]
* __getslice__, __setslice__, __delslice__ [17]_
* Remove slice opcodes and use slice objects
* __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,
@ -134,6 +135,7 @@ 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
@ -145,7 +147,8 @@ Atomic Types
To be removed:
* ``basestring.find()`` and ``basestring.rfind()``; use ``basestring.index()``
or ``basestring.rindex()`` in a try/except block??? [15]_
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]
@ -155,7 +158,7 @@ Built-in Namespace
==================
* Make built-ins return an iterator where appropriate (e.g. ``range()``,
``zip()``, etc.)
``zip()``, etc.) [zip is done; Neil 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
@ -174,9 +177,10 @@ To be removed:
* ``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]_
(Actually these can stay.)
* ``reduce()``: write a loop instead [2]_, [9]_ [done]
* ``raw_input()``: use ``sys.stdin.readline()`` ??? [2]_
* ``xrange()``: use ``range()`` instead [1]_ [See range() above]
Standard library