Unfortunately, Guido was developing a cold, or at least a cough, rightabout when he had to give his talk. So he had a trouble speakingwithout hoarseness. The presentation was still interesting: as theaudience almost certainly hoped, he made a mildly comical disparagementof the Perl 6 process by way of comparison—but strictly in thefriendliest manner, obviously without any hostility or competitivesentiment towards the Perl coders. His comment though was that the Perl6 methodology appeared to be for a group of developers to travel to adistant island, and remain there until they invented a new programminglanguage. In a somewhat more serious tone, he also contrasted Python 3.0with C++, where the latter is completely unwilling to accept even thesmallest backwards-compatibility breakage. Guido described Python 3.0as falling in the middle of these extremes.
Moreover, our BDFL announced a pretty concrete schedule for 3.0: Analpha should be available near the beginning of 2007, with a releaseversion before the end of the year. Python 2.6 will almost surely bereleased before the final 3.0, and the Python 2.x line will continue for a goodwhile to overlap 3.0 (because 3.0 will not run all the older Pythonprograms unmodified). Python 2.7 will probably contain some back-portsof 3.0 features, where they can be implemented without breakage; and 2.7will also probably contain a collection of migration tools. Guidoenvisions migration as relying on two classes of tools:
- Code analyzers along the lines of PyChecker and PyLint that can in many cases extract the intent of code, vis-a-vis the specific types of objects being handled. Most breakage will come about because particular types (think collections) behave somewhat differently than they used to. Guido gave the example of trying to determine whether
f(x.keys())represents code breakage. There are two points of concern here:
x.keys()really a call to a method of a dictionary(-like) object, as you would tend to think?
- As mentioned below, this call on a dictionary will start returning either an iterator or a view in Python 3.0, rather than a fixed list. Depending on what you do with it, the change may or may not matter to the code in
f(). I.e. if you just do "
for thing inkeys:", all is happy; if you mutate the expected list, problems occur. The exact fix is not generally automatable, since developers can reasonably want different behaviors in response to the change.
- Warnings about likely changes. Presumably with 2.7 (and later 2.x versions), there will be a means of warning developers of constructs that are likely to cause porting issues. In the simplest case, this will include deprecated functions and syntax constructs. But presumablythe warnings may cover "potential problems" like the above example.
dct.has_key(x)isgoing away, since nowadays you write
if x in dctanyway. Afew other relatively painless things along the same lines happen also. But moreinteresting is the fact that
lambdais not going anywere(it is also not being enhanced according to any of the numerousproposals). This little fact met with a surprising number of cheers (andprobably some less audible rolled eyes among a different subset of theaudience). Old style classes also go away, to everyone's approval; thatis not 100% breakage free, but it is just simply a good thing.Similarly with the removal of string exceptions, and the creation of a
BaseExceptionancestor of all exceptions. A little bit ofsyntax is simplified too. I will lose my dear
<>versionof inequality, but that is an awfully easy update.
Some new feature include:
- All strings become Unicode (breaky), and a new
bytestype lets you encode mutable arrays of 8-bit bytes. Basically, one is "text" the other is "binary data". Accompanying this will probably be a variety of mechanisms to make I/O methods inherently handle Unicode, transparently deal with decoding on
open(fname)and thelike (and also things like seeks).
- Inequality comparisons become even more breaky than they have been (see my recent Charming Python bemoaning inequalities). I have mixed feelings myself, but in a certain way I think it is a reasonable approach. Python will give up (most of) its willingness to guessabout what coders intend when comparing unlike types of things. Atleast that adds consistency. Rather than sometimes-but-who-knows-whenhaving sorts break, we can just assume they do not work unlesscollections are homogeneous, or unless heroic measures are taken inadvance (but as a known requirement).
- As expected, the move towards iterators and variations on lazy objects continues apace. List comprehensions do not go away, but they are direct synonyms (syntax sugar) for a
list()call wrapped around a generator comphrehension. This changes the leakage ofvariables to surroudning scope, which is a good thing.
Another thing I completely failed to notice until Paul McGavin pointedit out to me: Guido said nary a word about optional type declarations.Given what a hot button this idea is, the lacuna was surprising. Iwould not necessarily be surprised to hear he had decided against it; buthearing nothing at all, either way, is curious.