PyCon Friday: Guido's Keynote

Guido started by suggesting that this was going to be boring because it's the same talk as last year: Python 3.0 is coming, it's going to change everything, don't worry!

Matz, the author of Ruby, has said that "open source needs to move or die". Guido sees 3.0 as a chance to remove some of the sticky mistakes he made fairly early in the development of the language. Python is now 18 years old, its first open source release was in February 1991, and it's time for a change.

Guido gave a quick summary of major breakages. Most Python users by now re aware that the print statement is disappearing, that integer division is becoming a separate operator and so on. Guido was more interested in promoting the new features.

He feels that argument annotations will allow users to experiment with the feature, and that some interesting uses will eventually be available in the standard library. Abstract base classes offer an optional way to escape from duct typing. The wild-card unpacking assignment will offer more flexibility, and the new string formatting (similar to C#'s formatting feature), and many small improvements which he just displayed on one single slide.

Oberall Python 3.0 will become a smaller language, and some of the redundant older ways of doing things will be removed in the interests of keeping the language manageable and "fitting your brain". It is ready to evolve, and the new features provide the basis for that evolution. We have a good migration strategy (move to 2.6, then use warnings to make your 2.6 compatible with 2to3 automated translation).

There is no hurry - the 2.x series could be with us for another five years. In the meantime convert to new-style classes, stop using obsolete modules, and make more use of generators and iterators. Leave the small stuff to 2to3, the automated translator.

Porting C extensions may be more troublesome, because many API's will be removed.


Q (Jacob Kaplan-moss): One of Django's features is retaining compatibility with older Python versions, so a full port to 2.6 would effectively break backwards compatibility; what should our migration strategy be?

A: Migrate to 2.6 but don't immediately convert it for migration; track your user base and convert to 3.0-compatible source when it's practical without causing too many problems to your user base.

Q; 2to3 could be useful for frameworks that need to inport other people's code; will it be available with 3.0?

A: It would need some restructuring of the code, but is doesn't sound unreasonable; bring it up on the Python 3000 list, and offer to do a little of the work!

Q: Will the ABCs include an abstract sequence base class?

A: There's a container class, but not something explicit for sequences.

Q: What will the performance differences eventually be between 2.X and 3.0?

A: in the long term I don't anticipate much difference, though 3.0 may take a small hit initially.

Q: You said there would be no change to the whitespace issue - why not?

A: Most of the people here wouldn't let me! But the language is going to be stricter about the potentially damaging uses of mixed tabs and sapces.

Q: Is localization going to start working its way into the way we process strings?

A: I'll have to defer to others on that one; but there won't any longer be a need to work with data in specific encodings.

Q: I was expecting to be able to import 2.6 modules directly into 3.0 as opaque objects, avoiding the need to port legacy code; why can't this be done?

A: A virtual machine that's capable of running both 2.x and 3.0 bytecodes would be a great thing to have, but incompatibilities in the way the basic types operates make this not just ill-advised but impossible.

Q: Is there any change to the GIL strategy for 3.0? Our large applications with Python embedded need to take advantage of multiple CPUs.

A: For better of for worse, it's not going away, and there are good reasons for this, which have started to convince even the most reluctant. The pyprocessing module can help, or look at Jython or IronPython.