Differences between revisions 44 and 45
⇤ ← Revision 44 as of 2005-03-03 17:36:13 →
Size: 9190
Editor: 162
Comment: Comments on strict/lax code snippet didn't jive with explanation above.
← Revision 45 as of 2005-04-28 04:15:21 → ⇥
Size: 9507
Editor: c-67-165-222-53
Comment: traceback attribute to Exception instances
Deletions are marked like this. Additions are marked like this.
Line 83: Line 83:
 * 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.
Line 177: Line 179:
 * [[Anchor(r)]] [18] Python-Dev -- anonymous blocks: http://mail.python.org/pipermail/python-dev/2005-April/053060.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 #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: 

       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

  • Add a with statement: #j 10 

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

    • (I like this, but is the following too ugly for use until then? 

      •    1    #!python
   2     _ = self
   3     _.foo = [1, 2, 3]
   4     _.bar(4, _.foo)

    • .. seems quirky, but it does serve to remove most of the visual cluster of self.this and self.that which seems to be the primary benefit of the with statement.

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

    • GvR suggested the syntax #q 17: 

         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

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

  • 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 

       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.

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

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.