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

(At the time of writing there was already such a document #l 12, 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. #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:

     1 except E1, E2, E3 as err:  # Store error variable
     2    ...
  

  (Added by GvR, suggested by Bram Cohen.)

• Add a with statement: #j 10

     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.

  • One suggestion is to use an "as" keyword for this #o 15 and for adaptation #p 16:

       1 # "x as y" means: adapt x to the y protocol
       2 
       3 def foo (a as int, b as float) as float:
       4     a2 = a as float  # Same as: adapt(a, float)
       5     ...
    

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

• Require that the first statement of a suite be on its own line. #a 1

     1 if expression: statement
     2 
     3 # -->
     4 
     5 if expression:
     6     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.

• 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 Exception subclasses can be raised, 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?

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(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