Differences between revisions 61 and 62
Revision 61 as of 2008-07-12 00:12:48
Size: 11103
Editor: eth595
Comment: add reference to PEP 3108
Revision 62 as of 2008-11-15 14:01:02
Size: 11201
Editor: localhost
Comment: converted to 1.6 markup
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 18: Line 18:
 * 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]]
 * 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]]]
Line 30: Line 30:
 * Raise an exception when making comparisons (other than equality and inequality) between two incongruent types. [[#x 24]]  * Raise an exception when making comparisons (other than equality and inequality) between two incongruent types. [[[#x|24]]]
Line 32: Line 32:
 * Require that all exceptions inherit a common base class. [[#i 9]]  * Require that all exceptions inherit a common base class. [[[#i|9]]]
Line 34: Line 34:
 * Make the traceback a standard attribute of Exception instances [[#r 18]]  * Make the traceback a standard attribute of Exception instances [[[#r|18]]]
Line 36: Line 36:
 * Remove {{{`x`}}}. [[#a 1]]  * Remove {{{`x`}}}. [[[#a|1]]]
Line 41: Line 41:
 * Remove support for string exceptions. [[#a 1]]  * Remove support for string exceptions. [[[#a|1]]]
Line 58: Line 58:
   * GvR suggested the syntax [[#q 17]]: (but NOT for static typing - for declaring type information that would be checked at runtime, not compile time) {{{    * 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 80: 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 82: Line 82:
 * Remove `coerce()` as it is obsolete. [[#a 1]]  * Remove `coerce()` as it is obsolete. [[[#a|1]]]
Line 84: Line 84:
   * Reason: used for objects like `float`s where calling `__int__()` has data loss but an integral representation is still desired. [[#y 25]]    * Reason: used for objects like `float`s where calling `__int__()` has data loss but an integral representation is still desired. [[[#y|25]]]
Line 87: Line 87:
 * Remove `apply()`. [[#a 1]]  * Remove `apply()`. [[[#a|1]]]
Line 89: Line 89:
 * Remove `xrange()`. [[#a 1]] [[#d 4]]  * Remove `xrange()`. [[[#a|1]]] [[[#d|4]]]
Line 91: Line 91:
 * Remove `map()` and `filter()`. [[#a 1]] [[#d 4]]  * Remove `map()` and `filter()`. [[[#a|1]]] [[[#d|4]]]
Line 93: Line 93:
 * Remove `reduce()`. [[#a 1]]  * Remove `reduce()`. [[[#a|1]]]
Line 95: Line 95:
 * Remove `callable()`. [[#a 1]]  * Remove `callable()`. [[[#a|1]]]
Line 97: Line 97:
 * Remove `buffer()`. [[#a 1]] [[#b 2]]  * Remove `buffer()`. [[[#a|1]]] [[[#b|2]]]
Line 99: Line 99:
 * Remove `raw_input()`. [[#a 1]]  * Remove `raw_input()`. [[[#a|1]]]
Line 101: Line 101:
 * Remove `input()`. [[#a 1]]  * Remove `input()`. [[[#a|1]]]
Line 103: Line 103:
 * Remove `execfile()` and `reload()`. [[#a 1]]  * Remove `execfile()` and `reload()`. [[[#a|1]]]
Line 105: Line 105:
 * Remove `basestring.find()` and `basestring.rfind()`. [[#w 23]]  * Remove `basestring.find()` and `basestring.rfind()`. [[[#w|23]]]
Line 113: Line 113:
 * 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 125: Line 125:
 * 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 130: Line 130:
 * 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 135: Line 135:
 * 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?
Line 137: Line 137:
 * Should a `with` (or `using`) statement be added? [[#j 10]] [[#s 19]] {{{  * Should a `with` (or `using`) statement be added? [[[#j|10]]] [[[#s|19]]] {{{
Line 147: Line 147:
 * [[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(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
Line 150: Line 150:
 * [[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(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 158: Line 158:
 * [[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
 * <<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:

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:

       1 except E1, E2, E3 as err:  # Store error variable
       2    ...
    
    (Added by GvR, suggested by Bram Cohen.)
    • JimD's suggested syntax:

         1 except (E1, E2, E3), e:
         2    ...
         3 
         4 except E1, e:
         5    ...
      

      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)

         1 def bar(low: int, high: int) -> float:
         2     ...
      
    • 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:

         1 def baz(x as list, y as strict file):
         2     # x must only (be adapted to) implement part of the list interface
         3     # y must (be adapted to) implement the whole file interface 
      
    • Another proposal: Use -> and => as type conversion operators (lax and strict, respectively).

         1 def qux(x -> list, y => file):
         2     # x must only (be adapted to) implement part of the list interface
         3     # y must (be adapted to) implement the whole file interface 
      

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).

  • Remove xrange(). 1] 4]

    • Instead: use range().

  • Remove map() and filter(). 1] 4]

    • Instead: use list comprehensions.
  • Remove reduce(). 1]

    • Instead: use a loop.
  • Remove callable(). 1]

    • Instead: catch the exception.
  • Remove buffer(). 1] 2]

    • Instead: use new bytes type.

  • Remove raw_input(). 1]

    • Instead: use sys.stdin.readline().

  • Remove input(). 1]

    • Instead: use eval(sys.stdin.readline()).

  • 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.

  • 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

  • Should a with (or using) statement be added? 10] 19]

       1 with self:
       2     .foo = [1, 2, 3]
       3     .bar(4, .foo)
    

References

Python3.0 (last edited 2011-04-08 16:42:51 by ip-109-90-196-137)

Unable to edit the page? See the FrontPage for instructions.