Differences between revisions 21 and 22
Revision 21 as of 2004-08-27 04:21:36
Size: 5910
Editor: BrettCannon
Comment:
Revision 22 as of 2004-08-27 16:21:10
Size: 6093
Editor: cpe-68-112-255-10
Comment:
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
 * Make list comprehensions equivalent to passing a generator expression to `list()`
   * Reason: essentially the same and removes edge-case differences between the two
 * `as` a
keyword [[#g 7]]
 * Have `True` and `False` be keywords [[#f 6]]
   * Reason: stop assignment to them
 * T
rue division becomes default
 * Remove `__cmp__` (and possibly cmp() ) [[#h 8]]
  * Reason: TOOWTDI and rich comparisons are another way
 * Raise exception when comparing two heterogeneous types with operators other than `==` and `!=`
* Reason: comparisons do not make sense
 * Automatically h
ave types compare as not equal when types are heterogeneous [[#i 9]]
  * Reason: equality does not make sense between heterogeneous types
 * E
xceptions inherit from common base class [[#j 10]]
  * Reason: forces use of classes as objects raised by exceptions; simplifies implementation
 * Make list comprehensions equivalent to passing a generator expression to `list()`.
   * Reason: they are essentially the same and it would remove edge-case differences between them.
 * Ma
ke `as` a true keyword. [[#g 7]]
 * Make `True` and `False` keywords. [[#f 6]]
   * Reason: make assignment to them impossible.
 * Make t
rue division default.
 * Remove `__cmp__` (and possibly `cmp()`). [[#h 8]]
   * Reason: [TOOWTDI] and rich comparisons are another way.
 * Raise an exception when comparing two heterogeneous types with operators other than `==` and `!=`.
 
* Reason: such comparisons do not make sense, and are especially confusing to new users of Python.
 * H
ave types compare as unequal when they are heterogeneous. [[#i 9]]
   * Reason: equality does not make sense between heterogeneous types.
 * Require that all e
xceptions inherit a common base classs. [[#j 10]]
   * Reason: forces the use of classes as objects raised by exceptions and simplifies the implementation.
Line 98: Line 98:
 * Reorganize with more package structure
   * Reason: too many modules to have in a flat hierarchy
 * Reorganize standard library to have more package structure.
   * Reason: there are too many modules to keep a flat hierarchy.
Line 108: Line 109:
 * Keyword for allowing shadowing of built-ins?
 * Prevent injecting into another modules global namespace?
 * Should there be a keyword for allowing the shadowing of built-ins?
 * Should injecting into another module's global namespace be prevented?
Line 118: Line 120:
 * [[Anchor(f)]] [6] "Constancy of None" thread -- http://mail.python.org/pipermail/python-dev/2004-July/046294.html
 * [[Anchor(g)]] [7] " "as" to be a keyword?" thread -- http://mail.python.org/pipermail/python-dev/2004-July/046316.html
 * [[Anchor(h)]] [8] "lists vs. tuples" thread -- http://mail.python.org/pipermail/python-dev/2003-March/034073.html
 * [[Anchor(i)]] [9] another email from "lists vs. tuples" thread -- http://mail.python.org/pipermail/python-dev/2003-March/034074.html
 * [[Anchor(j)]] [10] "Exceptional inheritance patterns" thread -- http://mail.python.org/pipermail/python-dev/2004-August/047114.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
 * [[Anchor(i)]] [9] Python-Dev -- lists vs. tuples: http://mail.python.org/pipermail/python-dev/2003-March/034074.html
 * [[Anchor(j)]] [10] Python-Dev -- Exceptional inheritance patterns: http://mail.python.org/pipermail/python-dev/2004-August/047114.html

This page lists features that GvR has mentioned as goals for Python 3.0. This page has been consolidated into PEP 3000; the PEP is more up-to-date and is actively maintained. #e 5

(Another list is at PythonThreeDotOh, but it incorporates items that GvR has never talked about.)

Core Language Changes

  • Remove distinction between int and long types. #d 4

  • Make all strings unicode #d 4, and have a separate bytes #b 2 type.

  • 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), writeln(x,y,z)) #a 1

  • 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.)
  • Add a with statement:

       1 with self:
       2     .foo = [1, 2, 3]
       3     .bar(4, .foo)
    
  • 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.
  • Perhaps have optional declarations for static typing.
  • Make list comprehensions equivalent to passing a generator expression to list().

    • Reason: they are essentially the same and it would remove edge-case differences between them.
  • Make as a true keyword. #g 7

  • Make True and False keywords. #f 6

    • Reason: make assignment to them impossible.
  • Make true division default.
  • Remove __cmp__ (and possibly cmp()). #h 8

    • Reason: [TOOWTDI] and rich comparisons are another way.
  • Raise an exception when comparing two heterogeneous types with operators other than == and !=.

    • Reason: such comparisons do not make sense, and are especially confusing to new users of Python.
  • Have types compare as unequal when they are heterogeneous. #i 9

    • Reason: equality does not make sense between heterogeneous types.
  • Require that all exceptions inherit a common base classs. #j 10

    • Reason: forces the use of classes as objects raised by exceptions and simplifies the implementation.

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

Unresolved 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)?

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

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.