The Future of Python
Europython 2006 Keynote Talk by Guido van Rossum
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.
- 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
bytesdatatype, represented as a character array underneath. For strings always use encoding.
- Binary file I/O redesign. Use
bytesobjects 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
- kill classic classes
- all exceptions must derive from BaseException
- int/int will return a float
- remove last differences between int and long
- dict.has_key() (use in)
- file.xreadlines() and actually file and readlines()
- apply(), input(), buffer()
- 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
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.