[Python-checkins] r51768 - peps/trunk/pep-3100.txt

[guido.van.rossum]

Author: guido.van.rossum
Date: Wed Sep  6 08:42:42 2006
New Revision: 51768

Modified:
   peps/trunk/pep-3100.txt
Log:
Update status of various items.


Modified: peps/trunk/pep-3100.txt
==============================================================================
--- peps/trunk/pep-3100.txt	(original)
+++ peps/trunk/pep-3100.txt	Wed Sep  6 08:42:42 2006
@@ -64,19 +64,19 @@
 =============
 
 * 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 @@
   - 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 @@
   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 @@
 * 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 @@
 
 * 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 @@
 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 @@
 ==================
 
 * 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 @@
 * ``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