Python 3

This is a status page for keeping track of what needs to be done to make progress on Mercurial on Python 3.

1. Status

Support for Python 2 has been dropped for the Mercurial 6.2 release. 6.1.x is the last series to support Python 2.

Support for Python 3.5 has been dropped for the Mercurial 6.2 release. 6.1.x is the last series to support Python 3.5.

Mercurial 5.2 was the first release that officially had support for Python 3. Currently supported Python 3 versions are 3.6 and later. Mercurial with Python 3 on Windows is tested regularly, but there remains some known issues outside of the core.

It is the project policy for Mercurial and its core extensions to be compatible with Python 3. Over 99% of tests pass with Python 3 and test regressions are treated seriously.

Most used 3rd party extensions like evolve and topic have been ported to Python 3. There are some which have not yet been ported.

2. Using

Since Mercurial 5.2, setup.py no longer refuses to run with Python 3. pip install Mercurial or python setup.py install should work out of the box. But be aware that Windows support is still considered a beta level.

No run-time environment variable or config option is required to use Python 3 with Mercurial: only the installation step / setup.py requires special action to override the Python version check.

3. Things need to be investigated

• Windows encoding changes (fixed in 5.3)

  https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8

  Probably need to call sys._enablelegacywindowsfsencoding() at startup.

• Lazy importer performance overhead. Our custom importer on Python 2 always returns a stub module during import. Python 3's does I/O to verify the module exists then returns a lazy module that is loaded when first accessed. In addition to behavior differences, the I/O may contribute sufficient performance overhead to constitute a problem.

• A mechanism for extensions to advertise that they are Python 3 compatible. Nearly every extension will break in Python 3. We may want a mechanism that requires extensions to self-declare that they are Python 3 compatible - possibly via special syntax in their source code or the presence of a well-named variable. It might have to be at the source level because Python 3 would need to evaluate code in order to obtain the value of a module-level variable.

4. Porting Extensions to Python 3

Note Feb 2022: most major extensions have been ported to Python 3 a while back.

Nearly every extension will need to be ported to be compatible with Python 3. This is because of fundamental differences between Python 2 and Python 3.

The source code for Mercurial extensions will need to be Python 3 native and will need to be compatible with Mercurial's APIs. In many cases, existing source code will compile on Python 3 but will fail at run-time. Sources of run-time errors include:

• Use of str instead of bytes. Mercurial uses bytes (b'' strings) in almost all of its APIs and data structures. This is in contrast to much Python code, which uses str and '' strings. It is common for extensions to b'' prefix most strings in order to remain compatible with Mercurial.

• Use of iteritems(), iterkeys(), etc. These methods from core data structures do not exist in Python 3.

• Import of renamed modules. Python 3 refactored the locations of various modules in the Python standard library. Extensions may need to take this into account.

Do an Internet search for Python 3 porting to find well-written and comprehensive guides on generically porting code to Python 3.

Extension authors may find the mercurial.pycompat module useful. This modules contains abstractions and utilities for bridging the differences between Python 2 and 3. It is conceptually similar to the six Python module.

If you need help or guidance on porting extensions, you can message on IRC or the development MailingList. We will be happy to help you.

CategoryAudit