547
Comment:
|
9540
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
This page lists features that GvR has mentioned as goals for Python 3.0. | 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: |
* Reduce feature duplication: - string module vs. string methods - xrange() vs range() - int vs. long - 8 bit vs. Unicode strings - map/filter vs. list comprehensions - lambda vs. def * Library reorganization * Return iterators instead of lists - d.keys(), .values(), .items() - range(), zip(), map(), filter() * Consume iterators - min(), max() * Optional static typing? * Support only new-style classes; classic classes will be gone. |
If you have suggestions or comments for Python 3000, please add them to ["Python3.0Suggestions"]. |
Line 19: | Line 5: |
== Core Language Changes == * 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]] * Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`. For instance: {{{ #!python except E1, E2, E3 as err: # Store error variable ... }}} (Added by GvR, suggested by Bram Cohen.) ''JimD's suggested syntax: {{{#!python except (E1, E2, E3), e: ... except E1, e: ... }}} 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'' * 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 expression. * Remove support for string exceptions. [[#a 1]] * Instead: use a class. * Perhaps have optional declarations for static typing. * GvR suggested the syntax [[#q 17]]: (but NOT for static typing - for declaring type information that would be checked at runtime, not compile time) {{{ #!python def bar(low: int, high: int) -> float: ... }}} * 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: {{{ #!python def baz(x as list, y as strict file): # x must only (be adapted to) implement part of the list interface # y must (be adapted to) implement the whole file interface }}} * Another proposal: Use -> and => as type conversion operators (lax and strict, respectively). {{{ #!python 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 }}} * Make `as` a true keyword. (** Actually, this will happen '''sooner''' than 3.0! **) [[#g 7]] [[#t 20]] * Make `True` and `False` keywords. [[#f 6]] * Reason: make assignment to them impossible. * Make real 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]] {{{ #!python if expression: statement # --> if expression: statement }}} == Built-In Changes == * Have `range()`, `zip()`, `dict.keys()`, `dict.items()`, and `dict.values()` return iterators. * Move `compile()`, `intern()` and `id()` to the `sys` module. [[#a 1]] * Change `max()` and `min()` to consume iterators. * Remove `coerce()` as it is obsolete. [[#a 1]] * Remove `dict.iteritems()`, `dict.iterkeys()`, and `dict.itervalues()`. * Instead: use `dict.items()`, `dict.keys()`, and `dict.values()` respectively. * Remove `apply()`. [[#a 1]] * Instead: use `f(*args, **kw)`. * Remove `xrange()`. [[#a 1]] [[#d 4]] * Instead: use `range()`. * 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]] * Instead: use `exec()`. == Standard Library Changes == * 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'' * Remove `types` module. * Instead: use the types in `__builtins__`. * Remove other deprecated modules. [[#c 3]] * Remove `sys.exc_type`. [[#a 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? * 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]] * 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 [[#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. * 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 [[#n 14]], will old-style (`%(var)s`) substitutions be removed? * Should a `with` statement be added? (** No, ''this'' type of with statement has been rejected by the BDFL! **) [[#j 10]] [[#s 19]] [[#t 20]] {{{ #!python with self: .foo = [1, 2, 3] .bar(4, .foo) }}} == References == * [[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: * http://mail.python.org/pipermail/python-dev/2003-March/034073.html * http://mail.python.org/pipermail/python-dev/2003-March/034074.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] With Statement: http://wiki.python.org/moin/WithStatement |
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
If you have suggestions or comments for Python 3000, please add them to ["Python3.0Suggestions"].
Core Language Changes
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
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
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 expression.
Remove support for string exceptions. #a 1
- Instead: use a class.
- Perhaps have optional declarations for static typing.
GvR suggested the syntax #q 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).
Make as a true keyword. (** Actually, this will happen sooner than 3.0! **) #g 7 #t 20
Make True and False keywords. #f 6
- Reason: make assignment to them impossible.
- Make real 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
Built-In Changes
Have range(), zip(), dict.keys(), dict.items(), and dict.values() return iterators.
Move compile(), intern() and id() to the sys module. #a 1
Change max() and min() to consume iterators.
Remove coerce() as it is obsolete. #a 1
Remove dict.iteritems(), dict.iterkeys(), and dict.itervalues().
Instead: use dict.items(), dict.keys(), and dict.values() respectively.
Remove apply(). #a 1
Instead: use f(*args, **kw).
Instead: use range().
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.
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
Instead: use exec().
Standard Library Changes
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
- Instead: use string methods.
Remove types module.
Instead: use the types in __builtins__.
Remove other deprecated modules. #c 3
Remove sys.exc_type. #a 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?
Should the raise x, y syntax be removed as to favor raise x(y)?
If only Exception subclasses can be raised #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
- 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 #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.
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 #n 14, will old-style (%(var)s) substitutions be removed?
Should a with statement be added? (** No, this type of with statement has been rejected by the BDFL! **) #j 10 #s 19 #t 20
References
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(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(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] With Statement: http://wiki.python.org/moin/WithStatement