Skip to main content

Compile Python 3.6+ code to Python 2.7+

Project description


Compile Python 3.6+ code to Python 2.7+ compatible code. The idea is quite similar to Bable Develop using the newest interpreter and use (most) new language features without sacrificing backward compatibility.


MIT License Supported Python Versions PyCalVer v202002.0032 PyPI Version PyPI Downloads

Code Quality/CI:

Build Status Type Checked with mypy Code Coverage Code Style: sjfmt

Name role since until
Manuel Barkhau ( author/maintainer 2018-09 -

Project Status (as of 2020-02-21): Beta

I've been using this library for a year on a few projects without much incident. An example of such a project is PyCalVer. I have tested with Python 3.8 and made some fixes and updates. The library serves my purposes and I don't anticipate major updates, but I will refrain from calling it stable until there has been more adoption by projects other than my own.

Please give it a try and send your feedback.

In an ideal world, the project would cover all cases documented on and either:

  1. Transpile to code that will work on any version
  2. Raise an error, ideally pointing to a page and section on or other documentation describing alternative methods of writing backwards compatible code. also contains much info on API changes that might be checked for, but checks and fixers for these will only be written if they are common enough, otherwise it's just too much work (patches are welcome though).

Getting started with Development

$ git clone
$ cd lib3to6/
lib3to6 $ make install
lib3to6 $ make test
lib3to6 $ make help


The main motivation for this project is to be able to use mypy without sacrificing compatibility to older versions of python.

# my_module/
def hello(who: str) -> None:
    import sys
    print(f"Hello {who} from {sys.version.split()[0]}!")

$ pip install lib3to6
$ python -m lib3to6 my_module/
# -*- coding: utf-8 -*-
from __future__ import absolute_import
from __future__ import division
from __future__ import print_function
from __future__ import unicode_literals

def hello(who):
    import sys
    print('Hello {0} from {1}!'.format(who, sys.version.split()[0]))


Fixes are applied to match the semantics of python3 code as close as possible, even when running on a python2.7 interpreter.

Some fixes that have been applied:

- PEP263 magic comment to declare the coding of the python
  source file. This allows the string literal `"世界"` to
  be decoded correctly.
- `__future__` imports have been added. This includes the well
  known print statement -> function change. The unicode_literals
- Type annotations have been removed
- f string -> "".format  conversion

The cli command lib3to6 is nice for demo purposes, but for your project it is better to use it in your file.


import sys
import setuptools

packages = setuptools.find_packages(".")
package_dir = {"": "."}

if any(arg.startswith("bdist") for arg in sys.argv):
    import lib3to6
    package_dir = lib3to6.fix(package_dir)

~/my-module $ python bdist_wheel --python-tag=py2.py3
running bdist_wheel
~/my-module$ ls -1 dist/

~/my-module$ python3 -m pip install dist/my_module-201808.1-py2.py3-none-any.whl
Processing ./dist/my_module-201808.1-py2.py3-none-any.whl
Installing collected packages: my-module
Successfully installed my-module-201808.1

~/my-module$ python2 -m pip install dist/my_module-201808.1-py2.py3-none-any.whl
Processing ./dist/my_module-201808.1-py2.py3-none-any.whl
Installing collected packages: my-module
Successfully installed my-module-201808.1

To make sure we're importing my_module from the installation, as opposed to from the local directory, we have to switch directories.

~/$ python3 -c "import my_module"
Hello 世界 from 3.6.5!

~/my-module$ cd ..
~/$ python3 -c "import my_module"
Hello 世界 from 3.6.5!

~$ python2 -c "import my_module"
Hello 世界 from 2.7.15!

Feature Support

Not all new language features have a semantic equivalent in older versions. To the extent these can be detected, an error will be reported when these features are used.

An (obviously non exhaustive) list of features which are not supported:

  • async/await
  • yield from
  • @/matmul operator

Features which are supported:

  • PEP 498: formatted string literals.
  • Eliding of annotations
  • Unpacking generalizations
  • Keyword only arguments
  • PEP 515: underscores in numeric literals
  • map/zip/filter to itertools equivalents
  • Convert class based typing.NamedTuple usage to assignments

Some new libraries have backports, which warnings will point to:

  • typing
  • pathlib
  • secrets
  • ipaddress
  • csv -> backports.csv
  • lzma -> backports.lzma
  • enum -> flufl.enum

How it works

This project works at the level of the python abstract syntax tree (AST). The AST is transformed so that is only uses constructs that are also valid in older versions of python. For example it will translate f-strings to normal strings using the str.format method.

>>> import sys
>>> sys.version_info
>>> import lib3to6
>>> py3_source = 'f"Hello {1 + 1}!"'
>>> cfg = {"fixers": ["f_string_to_str_format"]}
>>> py2_source = lib3to6.transpile_module(cfg, py3_source)

>>> print(py3_source)
f"Hello {1 + 1}!"
>>> print(py2_source)
# -*- coding: utf-8 -*-
"Hello {0}!".format(1 + 1)

>>> print(lib3to6.parsedump_ast(py3_source))
    Str(s='Hello '),
>>> print(lib3to6.parsedump_ast(py2_source))
        value=Str(s='Hello {0}!'),

Of course this does not cover every aspect of compatibility. Changes in APIs cannot be translated automatically in this way.

An obvious example, is that there is no way to transpile code which uses async and await. In this case, lib3to6 will simply raise a CheckError. This applies only to your source code though, so if import use a library which uses async and await, everything may look fine until you run your tests on python 2.7.

A more subtle example is the change in semantics of the builtin open function.

$ cat
with open("myfile.txt", mode="w", encoding="utf-8") as fh:
    fh.write("Hello Wörld!")
$ python2
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: 'encoding' is an invalid keyword argument for this function

Usually there are alternative ways to write equivalent code that works on all versions of python. For these common incompatibilities lib3to6 will raise an error and suggest an alternative, such as in this case using instead.

$ lib3to6
Traceback (Most recent call last):
11  lib3to6      <module>         --> sys.exit(main())
764      __call__         --> return self.main(*args, **kwargs)
717      main             --> rv = self.invoke(ctx)
956      invoke           --> return ctx.invoke(self.callback, **ctx.params)
555      invoke           --> return callback(*args, **kwargs)
55  main             --> fixed_source_text = transpile.transpile_module(cfg, source_text)
260 transpile_module --> checker(cfg, module_tree)
158  __call__         --> raise common.CheckError(msg, node)
CheckError: Prohibited keyword argument 'encoding' to on line 1 of

Here lib3to6 you will give you a CheckError, however it remains your responsibility to write your code so that this syntactic translation is semantically equivalent in both python3 and python2.

lib3to6 uses the python ast module to parse your code. This means that you need a modern python interpreter to transpile from modern python to legacy python interpreter. You cannot transpile features which your interpreter cannot parse. The intended use is for developers of libraries who use the most modern python version, but want their libraries to work on older versions.


  • Q: Isn't the tagline "Compatibility Matters" ironic, considering that python 3.6+ is required to build a wheel?

  • A: The irony is not lost. The issue is, how to parse source code from a newer version of python than the python interpreter itself supports. You can install lib3to6 on older versions of python, but you'll be limited to the features supported by that version. For example, you won't be able to use f"" strings on python 3.5, but most annotations will work fine.

  • Q: Why keep python2.7 alive? Just let it die already!

  • A: Indeed, and lib3to6 can help with that. Put yourself in the shoes of somebody who is working on an old codebase. It's not realistic hold all other development efforts while the codebase is migrated and tested, while everything else waits.

    Instead an incremental approach is usually the only option. With lib3to6, individual modules of the codebase can be migrated to python3, leaving the rest of the codebase untouched. The project can still run in a python 2.7 environment, while developers increasingly move to using python 3.

    Additionally, lib3to6 is not just for compatibility with python 2.7, it also allows you to use new features like f"" strings and variable annotations, while still maintaining compatibility with older versions of python 3.

  • Q: Why not lib3to2?

  • A: I can't honestly say much about lib3to2. It seems to not be maintained and looking at the source I thought it would be easier to just write something new that worked on the AST level. The scope of lib3to6 is more general than 3to2, as you can use it even if all you care about is converting from python 3.6 to 3.5.

Changelog for


  • Compatibility fixes for Python 3.8
  • Add support for f-string = specifier
  • Add support for := walrus operator (except inside comprehensions)


  • Fix python 2 builtins were not always overridden correctly.
  • Fix pypy compatability testing
  • Better mypy coverage


  • Recursivly apply some fixers.


  • Move to
  • Use bootstrapit
  • Fix bugs based on use with pycalver


  • CheckErrors include log line numbers

  • Transpile errors now include filenames

  • Added fixers for renamed modules, e.g. .. code-block:: diff

     - import queue
     + try:
     +     import queue
     + except ImportError:
     +     import Queue as queue


  • Better handling of package_dir
  • Change to CalVer Versioning <>_
  • Remove console script in favour of simple python -m lib3to6
  • Rename from three2six -> lib3to6

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for lib3to6, version 202002.32
Filename, size File type Python version Upload date Hashes
Filename, size lib3to6-202002.32-py36.py37.py38-none-any.whl (31.6 kB) File type Wheel Python version py36.py37.py38 Upload date Hashes View hashes
Filename, size lib3to6-202002.32.tar.gz (42.4 kB) File type Source Python version None Upload date Hashes View hashes

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page