1. Objective
    2. Strategy
    3. Methodology
    4. Mechanical changes
    5. Reviewer check list
    6. Details
    7. Tips
    8. Lessons Learned
    9. Other
      1. Documentation


To have Twisted available on Python 3.3 and newer, with the same functionality as is currently available on Python 2.x.


  • Single source - The result will be a version of Twisted that is source-compatible with Python 2.7, and Python 3.3.
  • Test-driven - Following the standard Twisted development process, all changed code will be fully automatically unit tested.
  • Opportunistic - Where module dependencies (within Twisted) need to be ported to support porting of the high-priority modules, subsets of the module may be ported to provide specific functionality (but less than the full module).

All other standard Twisted development practices apply.

An initial minimal project ( was funded by Canonical and implemented by Future Foundries LLC (i.e. Itamar and Jean-Paul), with the aim of getting a basic subset of Twisted working, sufficient to run a specific Canonical project. That project has been completed, laying the groundwork for further porting effort by other developers.


  1. Choose a single module.
  2. Port the tests carefully; merely importing on Python 3 is insufficient. See the checklist below.
  3. Now that tests are importable, update the code carefully to pass all tests. If there is not full test coverage you may need to either write some tests, or sometimes just not include those parts of code in Python 3. The latter is easier if it's a standalone class.
  4. Deprecated code need not be ported, so if you notice some code that ought to be deprecated, open another ticket for that.

Mechanical changes

For syntax changes or stdlib reorganization changes or method replacement changes you can submit a patch targeting a specific change, even if they don't fully port a module.

Make sure the patch don't have more than 400 changes (removal + additions)

The changes in the diff need 100% coverage on Python 2.7.

If those lines were not previously covered, you need to write new tests.

Syntax changes don't need 100% coverage as they are tested just by compiling/loading the module. But make sure that the changes are imported during the tests.

You can use 2to3 as a starting point for performing mechanical changes. All changes produces by 2to3 need to be manually reviewed.

Reviewer check list

  1. Tests pass under 3.3.
  2. Ported modules were added to list of ported modules in [source:trunk/twisted/python/ twisted/python/]
  3. No warnings when running using -3 mode under Python 2.7.
  4. All non-docstring strings are clearly marked as one of the various string categories (bytes/unicode/identifier/version-dependent).
  5. No use of 'str' except for things that really can differ across versions of Python.
  6. from __future__ import division, absolute_import was added to the module.
    1. And any code changes necessary to work with the resulting changed semantics were made.
  7. Verify dictionary methods were ported correctly.
  8. All calls to open() files should be in binary mode.
  9. Unavoidable incompatibilities between Twisted APIs on Python 3 and the original behavior on Python 2 are documented in docs/core/howto/python3.rst (incompatibilities in the Python 2 behavior are not allowed).
  10. Python 3 changes from Python 2 are addressed, including but not limited to:
    • map(), filter(), etc. are lazy.
    • except Exception as e: for exceptions.
    • Dict keys(), values() and items() are wrapped in list() if they are expected to be an unchanging copy.
    • Bytes objects iteration and indexing return integers.
    • No byte paths in sys.path.
    • Etc..
  11. twisted.python.compat compatibility functions are used, rather than reinventing the wheel.
  12. _PY3 checks are ideally only done at top of module, e.g. to define alternate helper modules.
  13. If python 2 code is using an old style class we should always keep it as an old style class in Py2 and have a new style class only in the ported Py3 code as otherwise it might break the method resolution order


  1. Bootstrap the testing system
    1. Port the non-reactor parts of trial necessary to run the tests for the non-reactor parts of trial
      1. Refactor the implementation to separate the reactor and non-reactor parts into separate source files
      2. Add more tests for uncovered functionality
      3. Get the non-reactor parts passing their own tests on Python 3.3
    2. Test-driven port of the dependencies of the reactor features of trial
    3. Test-driven port of the reactor features of trial
  2. should only install ported modules on Python 3 (#6040, #6096, #7995).
  3. Test-driven port of the following modules (some of which may be dependencies of above steps):
  1. A graph with Python 3.3 status
  2. Python 3.3 porting milestone
  3. Build-slave for Python 3.3 should only run ported test modules.


  1. Select a module that needs to be ported (make sure there is a ticket, no one else has started it, etc).
  2. Add the module and its test module(s) to [source:trunk/twisted/python/ twisted/python/]
  3. Run [source:trunk/admin/run-python3-tests admin/run-python3-tests], optionally specifying the test modules being ported as additional arguments, if you want to initially run just the new tests.
  4. Fix syntax errors in the test module
    1. Note that at this point after the syntax errors have been fixed, twisted.*.test has no attribute <test module that you know exists> is often the unittest test runner's way of swallowing ImportErrors (see, which can be confirmed by running the module directly and fixing any tracebacks until the module can be imported without ImportErrors.
    2. If some of the APIs in the module are not being ported, add a del statement at the end of the module, guarded by an if _PY3 check, to get rid of all unported APIs.
  5. If there are syntax errors in modules depended on by the test module:
    1. See if the depended-on module has been split into a foo and _foopy3 module and if the APIs needed from it are already in the _foopy3 module.
      1. If so, switch the test module to using the _foopy3 module directly.
      2. If not, go back to the beginning using the depended-on module as the thing to port.
    2. See if the APIs are really needed. For example, if the dependency is trial (and trial is not yet ported), perhaps the test module could use (temporarily) the stdlib unittest module instead.
      1. If the APIs are not needed, switch them to something that has been ported or remove their use.
      2. If they are, go back to the beginning using the depended-on module as the thing to port.
  6. Make the tests pass on Python 2.6 and Python 2.7.
  7. Make the tests pass on Python 3.3.
    1. If only some of the APIs in the module are being ported, use the same del solution at the end of the test module to get rid of TestCase subclasses for unported APIs.
  8. Verify the tests still pass on all 3 versions of Python.
  9. Submit for review
  • Strings
    • Types
      • Python 2 largely conflates text and bytes in the str type, but offers unicode for unambiguous text usage.
      • Python 3 reduces the functionality of the str type and renames it to bytes, reflecting the intent that it be used for bytes only. It renames the unicode type to str.
      • There is a third kind of string, used to represent Python identifiers and docstrings. These are bytes in Python 2 and text in Python 3.
    • Plan
      • Python 2.x native (byte) strings will be changed to Python 3.x native (text) strings except where some particular consideration dictates something else. For example, strings which belong to APIs primarily related to network traffic (ie, strings that come out of or go into sockets) will remain as byte strings.
      • As a consequence, APIs which previously only supported Python 2.x native (byte) strings will be changed on Python 3.x to accept native (text) strings. Where there does not introduce a new requirement to choose an encoding, arbitrary text will be supported. Where it does and the choice of encoding is trivially obvious (for example, dealing with a protocol which mandates UTF-8 in an RFC), arbitrary text will be supported. Where the choice if encoding is not trivially obvious, only ASCII text will be supported.
      • A later porting pass will revisit these ASCII only sites and expand support to include arbitrary text.

Ideally we could omit a number of them:

  • twisted.python.hook (#5860)
  • twisted.python._initgroups (#4920)
  • twisted.python.deprecate - we will not be porting deprecated code, presumably, so hopefully we can omit the module. (trial depends on this, porting it is easier than selectively cutting out all the bits in trial and throughout the test suite that rely on the functionality)
  • twisted.python.win32 - windows is not a target platform for the initial release.
  • twisted.persisted.sob and twisted.persisted.styles - this is all useless and/or terrible.
  • No doubt some others we can get away with only porting part of the module.

Lessons Learned

These are things that won't necessarily have any bearing on the Twisted porting project. However, they may inform future porting efforts, either of Twisted-using applications or any other Python applications.

  • Initial porting effort was estimated by looking at what modules would be needed. This overlooked some modules because they are only imported inside functions.
  • Splitting up modules into two separate implementation modules, one for ported code and one for unported code, is disruptive (#6183). Particularly, it's a great source of huge merge conflicts for development not related to the Python 3 port.


Some further ideas to consider:


Documentation potentially requires porting as well. An individual example (ie, one of the runnable .py files in a doc/<project>/examples/ directory) can be treated much as a module for the purposes of the porting workflow. One difference, however, is that the example is not added to the list of ported modules in

As with the rest of Twisted, the goal for porting documentation should be a version which is compatible with all supported versions of Python (eg, at this time, Python 2.7, and Python 3.3).

Last modified 4 years ago Last modified on 12/31/2016 11:02:03 AM