Mercurial on Python 3000 status report (GSoC)

Alejandro Santos alejolp at
Fri Jul 3 20:52:46 CDT 2009


$ python3.1 hg --version
Mercurial Distributed SCM (version 9e88991a51aa)

Copyright (C) 2005-2009 Matt Mackall <mpm at> and others
This is free software; see the source for copying conditions. There is NO

This is the first report on the Py3k Mercurial port! Your comments are
most welcome :)

So far many of the DeprecationWarnings are gone, detected by running
the test suite using the -3 switch of Python 2.6. Most of the
remaining warnings are automatically fixed by the 2to3 tool.

There is a simple patch on my MQ against tests/ (which I
hope soon be pushed to one of Hg repos) that adds a -3 flag to keep
track of those warnings.

Most of the converted code by the 2to3 tool seems to be working fine,
but can't say for sure until some of the tests start passing. There
were some reports on a few bugs on the Python BTS for the 2to3 fixer,
and so far there was a really nice and fast response to fix them on

The test suite script is also working, but none of the test cases
pass. So far the main issue is the Unicode/bytes explicit conversion
that Py3k requires when reading and writing files (or a process output
in the case of the test suite).

On Py 3.0/3.1 The commands dispatcher and the on-line help seems to be
working fine.

In general, the main blocking task has been to keep a code as
compatible as possible with Python 2.4, 2.5, 2.6 and 3.1, and to be
the least intrusive against Hg code as possible. The Official Python
Recommendation to port an application to Py3k is to modernize the code
to Py 2.6 first (like using the new local-dot-import to import
modules, PEP-328).

It is somewhat unknown the kind of support Python 3.0 will receive
from the Python folks, but it seems that they won't release a 3.0.2
version (3.0.1 is on it's way). So we are going directly to 3.1.

Another reason to go directly to 3.1 (as Martin Geisler posted on the
list) is to use the "surrogateescape" character encoding (AKA UTF-8B),
from Python PEP-383. The idea is to be on the safe side when decoding
bytes representing unknown characters.

There is a work in progress for a compatibility layer, creating an
abstraction for some Py2/Py3 differences. It's going to be accessible
via mercurial.util, but I guess if it grows beyond some degree
(somewhat bigger than the current 3 functions + vars it contains)
might be neccesary to move it to it's own module (like

That's all for now. Comments are most welcome :)



More information about the Mercurial-devel mailing list