9507
Comment: traceback attribute to Exception instances
|
← Revision 66 as of 2011-04-08 16:42:51 ⇥
11286
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
This page lists features that ''Guido van Rossum himself'' has mentioned as goals for Python 3.0. Parts of this page have been consolidated into PEP 3000 [[#e 5]] | This page lists features that ''Guido van Rossum himself'' has mentioned as goals for Python 3.0. Parts of this page have been consolidated into PEP 3000 [[#e|[5]]] |
Line 3: | Line 3: |
If you have suggestions or comments for Python 3000, please add them to ["Python3.0Suggestions"]. | == Status == Python 3.0 is currently (2008-07-12) in beta testing, and has much accumulated documentation. More official sources of information include: * The development version of the Python 3.0 documentation: http://docs.python.org/dev/3.0/ * PEPs covering changes for Python 3.0: * PEP 3000, "Python 3000": http://www.python.org/dev/peps/pep-3000/ * PEP 3100, "Miscellaneous Python 3.0 Plans": http://www.python.org/dev/peps/pep-3100/ * PEP 3099, "Things that will Not Change in Python 3000": http://www.python.org/dev/peps/pep-3099/ * PEP 3108, "Standard Library Reorganization": http://www.python.org/dev/peps/pep-3108/ Unfortunately there does not appear to be a well-maintained single point of entry for someone to find all relevant changes that will occur in Python 3.0. |
Line 7: | Line 18: |
* Remove distinction between `int` and `long` types. [[#d 4]] ''(With 2.4 released, this is mostly done? -- JimD)'' * Make all strings unicode [[#d 4]], and have a separate `bytes` [[#b 2]] type. [[#m 13]] * Replace all old-style classes. [[#d 4]] * Make the `exec` statement a function (again.) [[#a 1]] * Make the `print` statement a function. (`write(x, y, z), writeline(x, y, z)`) [[#a 1]] |
* Remove distinction between `int` and `long` types. [[#d|[4]]] * Make true division the default behavior. [[#d|[4]]] * Make all strings unicode [[#d|[4]]], and have a separate `bytes` [[#b|[2]]] type. [[#m|[13]]] * Make the `exec` statement a function again. [[#a|[1]]] * Remove old-style classes. [[#d|[4]]] * Replace the `print` statement with a function or functions. (e.g. `write(x, y, z), writeline(x, y, z)`) [[#a|[1]]] [[#u|[21]]] * Make `as` a real keyword. [[#g|[7]]] * Add an attribute to exceptions for storing the traceback. [[#v|[22]]] * Remove `raise Exception, 'message'` syntax in favor of `raise Exception('message')`. [[#k|[11]]] [[#t|[20]]] * Require that the first statement of a suite be on its own line. [[#a|[1]]] * Make `True` and `False` keywords. [[#f|[6]]] * Reason: make assignment to them impossible. * Raise an exception when making comparisons (other than equality and inequality) between two incongruent types. [[#x|[24]]] * Reason: such comparisons do not make sense and are especially confusing to new users of Python. * Require that all exceptions inherit a common base class. [[#i|[9]]] * Reason: forces the use of classes as objects raised by exceptions and simplifies the implementation. * Make the traceback a standard attribute of Exception instances [[#r|[18]]] * Reason: inconvenient to pass the (type, value, traceback) triple that currently represents an exception around. * Remove {{{`x`}}}. [[#a|[1]]] * Instead: use `repr(x)`. * Reason: backticks are hard to read in many fonts and can be mangled by typesetting software. * Remove the `<>` operator. * Instead: use `!=`. * Remove support for string exceptions. [[#a|[1]]] * Instead: use a class. |
Line 17: | Line 47: |
}}} (Added by GvR, suggested by Bram Cohen.) | }}} (Added by GvR, suggested by Bram Cohen.) |
Line 27: | Line 57: |
* Add a `with` statement: [[#j 10]] {{{ #!python with self: .foo = [1, 2, 3] .bar(4, .foo) }}} ''(I like this, but is the following too ugly for use until then? {{{ #!python _ = self _.foo = [1, 2, 3] _.bar(4, _.foo) }}} ... seems quirky, but it does serve to remove most of the visual cluster of `self.`this and `self.`that which seems to be the primary benefit of the `with` statement. -- JimD)'' * Remove {{{`x`}}}. [[#a 1]] * Instead: use `repr(x)`. * Reason: backticks are hard to read in many fonts and can be mangled by typesetting software. * Remove the `<>` operator. * Instead: use `!=`. * Remove the `lambda` statement. [[#a 1]] [[#d 4]] * Instead: use a local function. * Reason: `lambda` supports only one statement. * Remove support for string exceptions. [[#a 1]] * Instead: use a class. |
|
Line 55: | Line 58: |
* One suggestion is to use an "as" keyword for this [[#o 15]] and for adaptation [[#p 16]]: {{{ #!python # "x as y" means: adapt x to the y protocol def foo (a as int, b as float) as float: a2 = a as float # Same as: adapt(a, float) ... }}} * GvR suggested the syntax [[#q 17]]: {{{ |
* GvR suggested the syntax [[#q|[17]]]: (but NOT for static typing - for declaring type information that would be checked at runtime, not compile time) {{{ |
Line 72: | Line 67: |
# y must (be adapted to) implement the whole file interface | # y must (be adapted to) implement the whole file interface |
Line 75: | Line 70: |
* Make `as` a true keyword. [[#g 7]] * Make `True` and `False` keywords. [[#f 6]] * Reason: make assignment to them impossible. * Make true division default. * Raise an exception when making comparisons between two incongruent types (other than equality and inequality.) * Reason: such comparisons do not make sense and are especially confusing to new users of Python. * Require that all exceptions inherit a common base classs. [[#i 9]] * Reason: forces the use of classes as objects raised by exceptions and simplifies the implementation. * Make the traceback a standard attribute of Exception instances [[#r 18]] * Reason: inconvenient to pass the (type, value, traceback) triple that currently represents an exception around. * Require that the first statement of a suite be on its own line. [[#a 1]] {{{ |
* Another proposal: Use -> and => as type conversion operators (lax and strict, respectively). {{{ |
Line 87: | Line 72: |
if expression: statement # --> if expression: statement |
def qux(x -> list, y => file): # x must only (be adapted to) implement part of the list interface # y must (be adapted to) implement the whole file interface |
Line 94: | Line 76: |
Line 100: | Line 80: |
* Move `compile()`, `intern()` and `id()` to the `sys` module. [[#a 1]] | * Move `compile()`, `intern()` and `id()` to the `sys` module. [[#a|[1]]] |
Line 102: | Line 82: |
* Remove `coerce()` as it is obsolete. [[#a 1]] | * Remove `coerce()` as it is obsolete. [[#a|[1]]] * Introduce `trunc()`, which would call the `__trunc__()` method on its argument. * Reason: used for objects like `float`s where calling `__int__()` has data loss but an integral representation is still desired. [[#y|[25]]] |
Line 105: | Line 87: |
* Remove `apply()`. [[#a 1]] | * Remove `apply()`. [[#a|[1]]] |
Line 107: | Line 89: |
* Remove `xrange()`. [[#a 1]] [[#d 4]] | * Remove `xrange()`. [[#a|[1]]] [[#d|[4]]] |
Line 109: | Line 91: |
* Remove `map()` and `filter()`. [[#a 1]] [[#d 4]] * Instead: use list comprehensions. * Remove `reduce()`. [[#a 1]] * Instead: use a loop. * Remove `callable()`. [[#a 1]] * Instead: catch the exception. * Remove `buffer()`. [[#a 1]] [[#b 2]] * Instead: use new `bytes` type. * Remove `raw_input()`. [[#a 1]] * Instead: use `sys.stdin.readline()`. * Remove `input()`. [[#a 1]] * Instead: use `eval(sys.stdin.readline())`. * Remove `execfile()` and `reload()`. [[#a 1]] |
* Remove `reduce()`. [[#a|[1]]] * Instead: use `functools.reduce()`. * Remove `callable()`. [[#a|[1]]] * Instead: use `hasattr` to check for `__call__` attribute. * Remove `buffer()`. [[#a|[1]]] [[#b|[2]]] * Instead: use new `bytes` type. * Remove `raw_input()`. [[#a|[1]]] * Instead: use `input()`. * Remove `input()`. [[#a|[1]]] * Instead: use `eval(input())`. * Remove `execfile()` and `reload()`. [[#a|[1]]] |
Line 123: | Line 103: |
* Remove `basestring.find()` and `basestring.rfind()`. [[#w|[23]]] * Instead: use `basestring.index()` and `basestring.rindex()` in a `try/except` block. |
|
Line 127: | Line 109: |
* Remove `string` module. [[#c 4]] * Instead: use string methods. ''There are things in the `string` module that I think belong there, for example `string.letters` and `string.digits`. I don't think that all the string manipulations that we might include with the standard libraries need to be in the core interpreter (any more than I would condone putting the regular expression engine into the core). --JimD'' |
|
Line 132: | Line 111: |
* Remove other deprecated modules. [[#c 3]] * Remove `sys.exc_type`. [[#a 1]] |
* Remove other deprecated modules. [[#c|[3]]] * Remove `sys.exc_type`. [[#a|[1]]] |
Line 142: | Line 121: |
* `L += x` and `L.extend(x)` are equivalent. | * `L += x` and `L.extend(x)` are equivalent. ''No, they are not. The former creates a new list without modifying the original list (which other people might have references to). The latter modifies the original list.'' |
Line 144: | Line 123: |
* Should the `raise x, y` syntax be removed as to favor `raise x(y)`? * If only `Exception` subclasses can be `raise`d [[#i 9]], should the `raise` statement be kept? Could `x(y).raise()` be used instead? * Are `repr()` and `str()` both needed? [[#a 1]] * Should `globals()`, `locals()` and `vars()` be removed? [[#a 1]] |
* If only `Exception` subclasses can be `raise`d [[#i|[9]]], should the `raise` statement be kept? Could `x(y).raise()` be used instead? * Are `repr()` and `str()` both needed? [[#a|[1]]] * Should `globals()`, `locals()` and `vars()` be removed? [[#a|[1]]] |
Line 150: | Line 128: |
* If line continuations (`\`) are removed from the language [[#a 1]], what should be done about the instances where statements do not allow parentheses? Furthermore, the Python style guide [[#k 11]] recommends their usage in some cases. * Should `__cmp__` (and possibly `cmp()`) be removed? [[#h 8]] * Reason: ["TOOWTDI"] and rich comparisons are another way. |
* If line continuations (`\`) are removed from the language [[#a|[1]]], what should be done about the instances where statements do not allow parentheses? Furthermore, the Python style guide [[#k|[11]]] recommends their usage in some cases. * Should `__cmp__` (and possibly `cmp()`) be removed? [[#h|[8]]] * Reason: [[TOOWTDI]] and rich comparisons are another way. |
Line 155: | Line 133: |
* With a new string substitution scheme [[#n 14]], will old-style (`%(var)s`) substitutions be removed? | * With a new string substitution scheme [[#n|[14]]], will old-style (`%(var)s`) substitutions be removed? * There are things in the `string` module that I think belong there, for example `string.letters` and `string.digits`. I don't think that all the string manipulations that we might include with the standard libraries need to be in the core interpreter (any more than I would condone putting the regular expression engine into the core). -- JimD * Should a `with` (or `using`) statement be added? [[#j|[10]]] [[#s|[19]]] {{{ #!python with self: .foo = [1, 2, 3] .bar(4, .foo) }}} |
Line 160: | Line 145: |
* [[Anchor(a)]] [1] Python Regrets: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf * [[Anchor(b)]] [2] PEP 296 -- Adding a bytes Object Type: http://python.org/peps/pep-0296.html * [[Anchor(c)]] [3] PEP 4 -- Deprecation of Standard Modules: http://python.org/peps/pep-0004.html * [[Anchor(d)]] [4] PyCon 2003 State of the Union Address: http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt * [[Anchor(e)]] [5] PEP 3000 -- Python 3.0 Plans: http://python.org/peps/pep-3000.html * [[Anchor(f)]] [6] Python-Dev -- Constancy of None: http://mail.python.org/pipermail/python-dev/2004-July/046294.html * [[Anchor(g)]] [7] Python-Dev -- "as" to be a keyword?: http://mail.python.org/pipermail/python-dev/2004-July/046316.html * [[Anchor(h)]] [8] Python-Dev -- lists vs. tuples: |
* <<Anchor(a)>> [1] Python Regrets: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf * <<Anchor(b)>> [2] PEP 296 -- Adding a bytes Object Type: http://python.org/peps/pep-0296.html * PEP 296 is withdrawn by the author in favor of PEP 358. * <<Anchor(c)>> [3] PEP 4 -- Deprecation of Standard Modules: http://python.org/peps/pep-0004.html * <<Anchor(d)>> [4] PyCon 2003 State of the Union Address: http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt * <<Anchor(e)>> [5] PEP 3000 -- Python 3.0 Plans: http://python.org/peps/pep-3000.html * <<Anchor(f)>> [6] Python-Dev -- Constancy of None: http://mail.python.org/pipermail/python-dev/2004-July/046294.html * <<Anchor(g)>> [7] Python-Dev -- "as" to be a keyword?: http://mail.python.org/pipermail/python-dev/2004-July/046316.html * <<Anchor(h)>> [8] Python-Dev -- lists vs. tuples: |
Line 170: | Line 156: |
* [[Anchor(i)]] [9] Python-Dev -- Exceptional inheritance patterns: http://mail.python.org/pipermail/python-dev/2004-August/047114.html * [[Anchor(j)]] [10] Python-Dev -- With statement: http://mail.python.org/pipermail/python-dev/2004-March/043545.html * [[Anchor(k)]] [11] PEP 8 -- Style Guide for Python Code: http://python.org/peps/pep-0008.html * [[Anchor(l)]] [12] PythonThreeDotOh * [[Anchor(m)]] [13] PEP 332 -- Byte vectors and String/Unicode Unification: http://python.org/peps/pep-0332.html * [[Anchor(n)]] [14] PEP 292 -- Simpler String Substitutions: http://python.org/peps/pep-0292.html * [[Anchor(o)]] [15] Python-Dev -- other uses for "as": http://mail.python.org/pipermail/python-dev/2004-February/042795.html * [[Anchor(p)]] [16] PEP 246 -- Object Adaption: http://www.python.org/peps/pep-0246.html * [[Anchor(q)]] [17] Python-Dev -- Decorators: vertical bar syntax: http://mail.python.org/pipermail/python-dev/2004-August/047424.html * [[Anchor(r)]] [18] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.html |
* <<Anchor(i)>> [9] Python-Dev -- Exceptional inheritance patterns: http://mail.python.org/pipermail/python-dev/2004-August/047114.html * <<Anchor(j)>> [10] Python-Dev -- With statement: http://mail.python.org/pipermail/python-dev/2004-March/043545.html * <<Anchor(k)>> [11] PEP 8 -- Style Guide for Python Code: http://python.org/peps/pep-0008.html * <<Anchor(l)>> [12] PythonThreeDotOh * <<Anchor(m)>> [13] PEP 332 -- Byte vectors and String/Unicode Unification: http://python.org/peps/pep-0332.html * <<Anchor(n)>> [14] PEP 292 -- Simpler String Substitutions: http://python.org/peps/pep-0292.html * <<Anchor(p)>> [16] PEP 246 -- Object Adaption: http://www.python.org/peps/pep-0246.html * <<Anchor(q)>> [17] Python-Dev -- Decorators: vertical bar syntax: http://mail.python.org/pipermail/python-dev/2004-August/047424.html * <<Anchor(r)>> [18] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.html * <<Anchor(s)>> [19] PEP 340 -- loose ends: http://mail.python.org/pipermail/python-dev/2005-May/053252.html * <<Anchor(t)>> [20] Python-Dev -- PEP 8: exception style: http://mail.python.org/pipermail/python-dev/2005-August/055190.html * <<Anchor(u)>> [21] Python-Dev -- Replacement for print in Python 3.0: http://mail.python.org/pipermail/python-dev/2005-September/056154.html * <<Anchor(v)>> [22] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.html * <<Anchor(w)>> [23] Python-Dev -- Remove str.find in 3.0?: http://mail.python.org/pipermail/python-dev/2005-August/055705.html * <<Anchor(x)>> [24] Python-Dev -- Comparing heterogeneous types: http://mail.python.org/pipermail/python-dev/2004-June/045111.html * <<Anchor(y)>> [25] Python-Dev -- Fixing _PyEval_SliceIndex so that integer-like objects can be used: http://mail.python.org/pipermail/python-dev/2005-February/051674.html |
This page lists features that Guido van Rossum himself has mentioned as goals for Python 3.0. Parts of this page have been consolidated into PEP 3000 [5]
Status
Python 3.0 is currently (2008-07-12) in beta testing, and has much accumulated documentation. More official sources of information include:
The development version of the Python 3.0 documentation: http://docs.python.org/dev/3.0/
- PEPs covering changes for Python 3.0:
PEP 3000, "Python 3000": http://www.python.org/dev/peps/pep-3000/
PEP 3100, "Miscellaneous Python 3.0 Plans": http://www.python.org/dev/peps/pep-3100/
PEP 3099, "Things that will Not Change in Python 3000": http://www.python.org/dev/peps/pep-3099/
PEP 3108, "Standard Library Reorganization": http://www.python.org/dev/peps/pep-3108/
Unfortunately there does not appear to be a well-maintained single point of entry for someone to find all relevant changes that will occur in Python 3.0.
Core Language Changes
Remove distinction between int and long types. [4]
Make true division the default behavior. [4]
Make all strings unicode [4], and have a separate bytes [2] type. [13]
Make the exec statement a function again. [1]
Remove old-style classes. [4]
Replace the print statement with a function or functions. (e.g. write(x, y, z), writeline(x, y, z)) [1] [21]
Make as a real keyword. [7]
Add an attribute to exceptions for storing the traceback. [22]
Remove raise Exception, 'message' syntax in favor of raise Exception('message'). [11] [20]
Require that the first statement of a suite be on its own line. [1]
Make True and False keywords. [6]
- Reason: make assignment to them impossible.
Raise an exception when making comparisons (other than equality and inequality) between two incongruent types. [24]
- Reason: such comparisons do not make sense and are especially confusing to new users of Python.
Require that all exceptions inherit a common base class. [9]
- Reason: forces the use of classes as objects raised by exceptions and simplifies the implementation.
Make the traceback a standard attribute of Exception instances [18]
- Reason: inconvenient to pass the (type, value, traceback) triple that currently represents an exception around.
Remove `x`. [1]
Instead: use repr(x).
- Reason: backticks are hard to read in many fonts and can be mangled by typesetting software.
Remove the <> operator.
Instead: use !=.
Remove support for string exceptions. [1]
- Instead: use a class.
Add a mechanism so that multiple exceptions can be caught using except E1, E2, E3:. For instance:
(Added by GvR, suggested by Bram Cohen.)JimD's suggested syntax:
The except code would then basically do the equivalent of if issubclass(arg1, Exception) or isinstance(arg1, Exception): ... else if len(arg1): ... (excepting, obviously, that this is implemented at a lower level in the C core). --JimD
- Perhaps have optional declarations for static typing.
GvR suggested the syntax [17]: (but NOT for static typing - for declaring type information that would be checked at runtime, not compile time)
Since some types only implement parts of an interface have 'strict' and 'lax' interfaces. Strict requires a complete implementation of the interface, lax requiring only a partial implementation with the rest being taken from interface defaults or ignored. This would require a new keyword/reserved word (strict) with lax mode being the default. This is to help duck typing. Ex:
Another proposal: Use -> and => as type conversion operators (lax and strict, respectively).
Built-In Changes
Have range(), zip(), dict.keys(), dict.items(), and dict.values() return iterators.
Move compile(), intern() and id() to the sys module. [1]
Change max() and min() to consume iterators.
Remove coerce() as it is obsolete. [1]
Introduce trunc(), which would call the __trunc__() method on its argument.
Reason: used for objects like floats where calling __int__() has data loss but an integral representation is still desired. [25]
Remove dict.iteritems(), dict.iterkeys(), and dict.itervalues().
Instead: use dict.items(), dict.keys(), and dict.values() respectively.
Remove apply(). [1]
Instead: use f(*args, **kw).
Instead: use range().
Remove reduce(). [1]
Instead: use functools.reduce().
Remove callable(). [1]
Instead: use hasattr to check for __call__ attribute.
Instead: use new bytes type.
Remove raw_input(). [1]
Instead: use input().
Remove input(). [1]
Instead: use eval(input()).
Remove execfile() and reload(). [1]
Instead: use exec().
Remove basestring.find() and basestring.rfind(). [23]
Instead: use basestring.index() and basestring.rindex() in a try/except block.
Standard Library Changes
Remove types module.
Instead: use the types in __builtins__.
Remove other deprecated modules. [3]
Remove sys.exc_type. [1]
Instead: use sys.exc_info.
- Reason: it is not thread safe.
- Reorganize standard library to have more package structure.
- Reason: there are too many modules to keep a flat hierarchy.
Open Issues
L += x and L.extend(x) are equivalent. No, they are not. The former creates a new list without modifying the original list (which other people might have references to). The latter modifies the original list.
Can the parameter order of the insert method be changed so the the index parameter is optional and list.append may be removed?
If only Exception subclasses can be raised [9], should the raise statement be kept? Could x(y).raise() be used instead?
Are repr() and str() both needed? [1]
Should globals(), locals() and vars() be removed? [1]
- Should there be a keyword for allowing the shadowing of built-ins?
- Should injecting into another module's global namespace be prevented?
If line continuations (\) are removed from the language [1], what should be done about the instances where statements do not allow parentheses? Furthermore, the Python style guide [11] recommends their usage in some cases.
Should __cmp__ (and possibly cmp()) be removed? [8]
Reason: TOOWTDI and rich comparisons are another way.
Should list comprehensions be equivalent to passing a generator expression to list()?
- Reason: they are essentially the same and it would remove edge-case differences between them.
With a new string substitution scheme [14], will old-style (%(var)s) substitutions be removed?
There are things in the string module that I think belong there, for example string.letters and string.digits. I don't think that all the string manipulations that we might include with the standard libraries need to be in the core interpreter (any more than I would condone putting the regular expression engine into the core). -- JimD
References
[1] Python Regrets: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf
[2] PEP 296 -- Adding a bytes Object Type: http://python.org/peps/pep-0296.html
- PEP 296 is withdrawn by the author in favor of PEP 358.
[3] PEP 4 -- Deprecation of Standard Modules: http://python.org/peps/pep-0004.html
[4] PyCon 2003 State of the Union Address: http://www.python.org/doc/essays/ppt/pycon2003/pycon2003.ppt
[5] PEP 3000 -- Python 3.0 Plans: http://python.org/peps/pep-3000.html
[6] Python-Dev -- Constancy of None: http://mail.python.org/pipermail/python-dev/2004-July/046294.html
[7] Python-Dev -- "as" to be a keyword?: http://mail.python.org/pipermail/python-dev/2004-July/046316.html
[8] Python-Dev -- lists vs. tuples:
[9] Python-Dev -- Exceptional inheritance patterns: http://mail.python.org/pipermail/python-dev/2004-August/047114.html
[10] Python-Dev -- With statement: http://mail.python.org/pipermail/python-dev/2004-March/043545.html
[11] PEP 8 -- Style Guide for Python Code: http://python.org/peps/pep-0008.html
[12] PythonThreeDotOh
[13] PEP 332 -- Byte vectors and String/Unicode Unification: http://python.org/peps/pep-0332.html
[14] PEP 292 -- Simpler String Substitutions: http://python.org/peps/pep-0292.html
[16] PEP 246 -- Object Adaption: http://www.python.org/peps/pep-0246.html
[17] Python-Dev -- Decorators: vertical bar syntax: http://mail.python.org/pipermail/python-dev/2004-August/047424.html
[18] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.html
[19] PEP 340 -- loose ends: http://mail.python.org/pipermail/python-dev/2005-May/053252.html
[20] Python-Dev -- PEP 8: exception style: http://mail.python.org/pipermail/python-dev/2005-August/055190.html
[21] Python-Dev -- Replacement for print in Python 3.0: http://mail.python.org/pipermail/python-dev/2005-September/056154.html
[22] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.html
[23] Python-Dev -- Remove str.find in 3.0?: http://mail.python.org/pipermail/python-dev/2005-August/055705.html
[24] Python-Dev -- Comparing heterogeneous types: http://mail.python.org/pipermail/python-dev/2004-June/045111.html
[25] Python-Dev -- Fixing _PyEval_SliceIndex so that integer-like objects can be used: http://mail.python.org/pipermail/python-dev/2005-February/051674.html