The Future of Python

Lambda is not going away, so don't worry about that. (Applause)

Python 3000 philosophy

• Don't design a new language. No pet peaves like adding a switch statement, redoing the if statement or whatever.
• Fix early design bugs.
• Allow incompatible changes (within reason). We're not maximizing breakage of course.
• Get rid of (morally) deprecated features. Old style classes are no longer the default.

Python 3000 process:

• We have to make selections. Too many proposals compete for time.
• Maintaining python 2 is a big issue. Back porting may be partly possible.

Release Schedule

• First alpha: not before next year.
• Final release: probably a year after that
• 3.1 and 3.2 may follow soon after for fairly small but logical changes.
• 2.6 will come, 2.7 likely, 2.9 is as far as we'll go.

How incompatible can it be?

• new keywords allowed
• dict.keys(), range(), zip() won't return lists. This kills dict.iterkeys(), xrange(), itertools.izip()
• All strings will be unicode. Mutable bytes datatype, represented as a character array underneath. For strings always use encoding.
• Binary file I/O redesign. Use bytes objects when reading from or writing to files.
• Drop '
• as alias for !='.
• But not:
  • dict.keys instead of dict.keys()
  • change meaning of else-clause of for/while
  • change operator priorities

How to migrate code?

• Perfect mechanical translation will not be possible. Many changes are semantic rather than syntactic. So a live programmer will need to look at it. Tools like pychecker can help though.
• Most likely approach:
  • Use pychecker-like tools to do an 80 percent job.
  • Create python 2 version that warns about dead ends.

Python 3000 will not:

• have macros, programmable syntax, etc
• add syntax for parallelization (use zip())

Python 3000 features: read PEP 3100 for a large list. See the peps

Basic cleanup:

• kill classic classes
• all exceptions must derive from BaseException
• int/int will return a float
• remove last differences between int and long
• kill:
  • sys.exc_type()
  • dict.has_key() (use in)
  • file.xreadlines() and actually file and readlines()
  • apply(), input(), buffer()

Minor syntactics:

• exec becomes a function again
• kill `x` in favor of repr(x)
• range() will behave like xrange()
• xrange() dies
• zip() becomes izip(0
• lambda lives! The lambda lovers tried for a year to come up with a better version, but failed. But it has its uses, so it can stay.

String types reform:

• bytes and str instead of str and unicode
• maybe bitwise operations on bytes, but that might add too much to to API.
• All data is either binary or text.

New standard I/O stack

• C stdio has too many problems
• bytes/str gives an opportunity to fix all this.

Print becomes a function!

• print x, y, z becomes print(x, y, z)
• print >> f, x, y, z becomes print(x, y, z, file=f)
• This makes it much easier to switch use logging.
• Skip the space or newline? Use printf() or printraw() or whatever we come up with.

Drop default inequalities: <= and friends are not useful between unrelated objects of different types. '== and !=' should always be possible.

Thanks to the Google team for T-shirts and sponsoring!

If it is possible to make a 2.x version that is somehow compatible with 3.0 then that would be nice.