On 8 May 2008, a day before the second PyCon Italia opened in Florence, Python 2.6a3 and 3.0a5 shipped as a pair, following the schedule fixed in PEP 361. The conference (9–11 May) therefore falls in the middle of the monthly alpha cycle leading to the two final releases planned for the autumn, and much of the hallway chatter circles the same question: what does it actually take to move code from Python 2 to Python 3.

Context

PEP 361 describes a coordinated release: 2.6 and 3.0 ship together, on the first Wednesday of each month during testing. The published sequence so far is 2.6a1/3.0a3 on 29 February, 2.6a2/3.0a4 on 2 April, 2.6a3/3.0a5 on 8 May. Betas are expected from June, 2.6 final in October, 3.0 final by the end of the year.

Keeping the two lines aligned is not a cosmetic choice. PEP 3000 is explicit that 3.0 breaks backward compatibility: there is no guarantee that 2.x code runs unchanged under 3.0, not even for a subset of the language. The breakages have been known for a while: print becomes a function, strings move to Unicode by default with a separate bytes type, integer division changes behaviour, dict.keys() and friends return views instead of lists. The point of 2.6 is to act as a bridge: developers on 2.6 can switch on the incompatibility warnings and use the names of the reorganised standard library, so they can prepare their code before the jump.

The migration problem

The question that keeps coming back at the conference is who can afford to move, and when — not whether Python 3 is better. The answer depends almost entirely on dependencies.

A program that uses only the standard library can be migrated with 2to3, the automatic translation tool that ships alongside 3.0a5 and rewrites the most common syntactic patterns. But 2to3 translates syntax, not semantics, and above all it leaves third-party libraries untouched — and in May 2008 nearly all of them are still on Python 2. For anyone building on a stack — an ORM, an application server, a web framework — migration stays blocked until every link in the chain is ported. In the Italian talks the real constraint is just this: what weighs is not the effort of rewriting one’s own code, it is the wait for the ecosystem underneath to move.

The state of the web ecosystem

The web track at PyCon Italia shows an ecosystem already settled around Python 2, grown on a standard that predates the 3.0 transition by years. PEP 333, the Web Server Gateway Interface (WSGI) proposed by Phillip J. Eby in 2003, defines the interface between web servers and Python applications and has decoupled the two sides: a WSGI-conformant application runs under any conformant server, and middleware composes in layers.

The frameworks running in the talks all sit on this interface. Django has shipped 0.96 and is working towards 1.0; Pylons puts Mako and Paste on top of WSGI; TurboGears exposes a WSGI front-end. On the Zope/Plone side — the stack on which a sizeable slice of Italian CMS development rests — migrating to Python 3 is a problem of a different scale altogether: years of code, the ZODB, the component architecture. WSGI is why this ecosystem copes well with the split between servers and applications, but it remains an abstraction that does not make the move to 3.0 any simpler: the interface is the same, the language underneath changes.

The critical point

String handling is the fault line that weighs most on web code. In Python 2 str is a byte sequence and unicode is a separate type; the implicit conversion between the two, convenient as long as everything is ASCII, blows up into a UnicodeDecodeError the moment non-ASCII text arrives. In Python 3 the default flips: str is Unicode text and bytes get a dedicated type, with no implicit coercion.

For a web application this touches exactly the hot spots: HTTP request bodies, headers, query parameters, database rows, templates. 2.x code that mixes str and unicode while relying on automatic conversion does not just fail the 2to3 translation: it calls for a manual review of the byte/text boundary at every point of I/O. That is the work separating a mechanical migration from a real one, and the concrete reason libraries will take time.

Implications

For anyone working in Python now the operational choice is clear: develop on 2.6 once it ships stable, switch on the deprecation warnings, write code that runs clean under -3, and defer the move to 3.0 until the critical dependencies are ported. 2.6 should be taken as a tool, not skipped as an intermediate step: it makes the next jump verifiable, where otherwise one would be working in the dark.

For the Italian ecosystem represented here — heavily Zope/Plone, a web community grown on WSGI — this means the transition will be measured in years, not months, and will go bottom-up: base libraries first, then frameworks, then applications. A PyCon in the middle of this cycle serves precisely to coordinate that movement, putting the people who maintain the libraries and the people who run them in production in the same room. Among those backing this edition is noze, which appears among the conference sponsors: https://www.noze.it/en/insights/pycon-due-italia/.

Limits

These notes are taken in the thick of the alpha phase: 3.0a5 is a development snapshot, the APIs are not frozen, and details cited here may change before the final release at the end of 2008. The dates themselves are the ones planned in PEP 361, and in Python projects slippage is the rule more than the exception. On the state of the frameworks, this is a snapshot of May 2008: version numbers and the degree of WSGI coverage should be checked at the source before relying on them for a migration decision.

Cover image: Guido van Rossum, the creator of Python, speaking while seated at Google I/O 2008; a bearded man with glasses in a light shirt — photo by Alessio Bragadini, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Guido_van_Rossum_at_Google_IO_2008.jpg