Differences between revisions 39 and 40
⇤ ← Revision 39 as of 2004-12-29 20:32:50 →
Size: 11733
Editor: c-67-165-222-53
Comment:
← Revision 40 as of 2004-12-30 15:29:40 → ⇥
Size: 11506
Editor: pcp07851501pcs
Comment:
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 has been consolidated into PEP 3000; the PEP is more up-to-date
and is actively maintained. [[#e 5]]		 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 5: Line 3:
(At the time of writing there was already such a document [[#l 12]], but it
incorporates items that GvR has never talked about.)

 ''Non-GvR sanctioned comments added below by JimD and StevenBethard''
    ''I can't help but wonder if there's a better place on this wiki for these comments. --JimD''		 If you have suggestions or comments for Python 3000, please add them to ["Python3.0Suggestions"].

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

  • Make as a true keyword. #g 7

  • Make True and False keywords. #f 6

    • Reason: make assignment to them impossible.

      • Note that this isn't currently possible due to backwards compatibility concerns; a lot of code trying to support versions of Python before and after True and False were introduced looked something like 

           1 try:
   2     True, False
   3 except NameError:
   4     True, False = 0 == 0, 0 == 1

        If True and False were keywords, this would cause a syntax error as potential assignment to None does in Python 2.4: 

           1 >>> try:
   2 ...     None
   3 ... except NameError:
   4 ...     None = 0
   5 Traceback (SyntaxError: assignment to None)

        Even though we never reach the assignment in the except block, we get a SyntaxError. This is because SyntaxErrors happen well before any code is executed. -- StevenBethard

  • 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

  • I'd like to see argument parsing use iterators instead of tuples when applicable. This would allow code like: 

       1 >>> def f(x, y, *args):
   2 ...     print x, y, repr(args)
   3 ...
   4 >>> f(*itertools.count())
   5 ... 0 1 'count(2)'

    Currently, this code causes an infinite loop because Python's argument parsing mechanism fully expands an iterator into a tuple when used in a *args context as above. When iterators are the standard, I would hope that instead of fully expanding the iterator, only the elements from the iterator necessary to fill positional arguments would be extracted. See the thread "Python 3000, zip, *args and iterators" #r 18 for more discussion of this idea and a real life example of where this might be useful. -- StevenBethard

    • Dare I even suggest that a ***args form could be used in some bizarre way? Personally I think the idea is unspeakably ugly and can't see any real world use for this.

      On the other hand I've often wished for something like: (a, b, *c) = foo.parse(filedescriptor.readline()) which would unpack the first arg into a, the next into b, and the rest into c. This desire is probably the result of years of shell scripting where I routinely use code like ps fax | while read pid x x x cmd args; do ... and don't care if args is empty or contains an interminately long list of items. I'm still not sure I'd seriously recommend it to Python. --JimD

      • Note that my proposal is not this extreme; I'm still only talking about *args in a function definition. All I'm suggesting is that since only the first N items of the iterator are needed, there's no need to convert the entire iterator into a tuple. Just pop off the necessary items from the front of the iterator and bind the args variable to the iterator containing the remaining items. The only change this makes to the language is that *args names in function definitions will be bound to iterator objects instead of tuple objects. -- StevenBethard

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.