Differences between revisions 27 and 28
Revision 27 as of 2004-08-27 21:52:05
Size: 6550
Editor: cpe-68-112-255-10
Comment:
Revision 28 as of 2004-09-01 00:25:01
Size: 6964
Editor: cpe-68-112-255-10
Comment: Added new references and moved __cmp__.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
(Another list is at PythonThreeDotOh, but it incorporates items that GvR has never talked about.) (At the time of writing there was already such a document [[#l 12], but it
incorporates items that GvR has never talked about.)
Line 10: Line 11:
 * Make all strings unicode [[#d 4]], and have a separate `bytes` [[#b 2]] type.  * Make all strings unicode [[#d 4]], and have a separate `bytes` [[#b 2]] type. [[#m 13]]
Line 46: Line 47:
 * 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.
Line 52: Line 51:
 * Remove `__cmp__` (and possibly `cmp()`). [[#h 8]]
   * Reason: ["TOOWTDI"] and rich comparisons are another way.
Line 109: Line 106:
== Unresolved Issues == == Open Issues ==
Line 119: Line 116:
 * 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?
Line 136: Line 138:
 * [[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

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

  • 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

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.