This page describes efforts to port PyLint to Python 3.x

Status of the port

• We're really just getting started.
• Dan's started running unit tests against preexisting code, to see what sort of preexisting conditions there may be. There are some dependencies to take care of.
• Dan has a bunch of different versions of CPython, one Jython, and two Pypy's for testing - all installed on one machine.

• Here's the ticket about the port

Goals and high level overview of tasks

The idea is to add support for Python 3.0 and 3.1, while eliminating Python 2.4 compatibility because that will simplify some of the code.

• This will require one of the following methods:
  • Converting the three Python 2-compatible packages to a common subset of Python 2 and Python 3
    • We may or may not be able to do this using 2to3; 2to3 may or may not prove too exuberant about moving to a nice, python 3-only syntax in some areas.
  • Creating modules that abstract the differences between Python 2 and 3 and depending on them instead.
• About the three packages
  • Those three packages are:
    1. logilab-common
       • This one is probably the place to start, because it appears to contain the test harness we need.
       • The owners of the code believe this will be the easiest part
       • 29274 lines of code initially
    2. logilab-astng
       • 18928 lines of code initially

    3. PyLint itself

       • 28415 lines of code initially
  • There appear to be test suites for each of these, which can be invoked using the pytest command - pytest appears to be part of logilab-common, which suggests a bit of
    • mutual dependency to work around.
• Dealing with a python 2 to python 3 port:
  • The four main ways:
    1. Automatically, fully derive your 3.x code from 2.x
    2. Make code run unmodified on 2.x and 3.x
    3. Maintain two parallel versions
    4. Port to 3.x mostly automatically using 2to3, then manually fix what's left that needs to be changed. Then automatically, fully derive the 2.x code from the new 3.x code.
  • The owners of the code prefer methods #1 and #2 over #3 above; we've not yet discussed method 4.

  • Note that Mercurial, the SCM system used by Py<int, supports changesets - this could take most of the labor out of method 3

Resources

These are all things related to doing Python 2 to 3 ports:

• 2to3

  • 2to3 documentation

  • Python Wiki on 2to3

• Notes about how to do 2 to 3 ports

  • Porting to Python 3: A Guide

  • Python 3 in Python 2.6+

  • Pycon 2009: Python 3 Compatibility (It's a movie of slides, but there's a transcript below that

    • on the page)

  • Nice cheat sheet about python 2 and python 3 equivalents - pretty detailed

• Specific projects' notes on their ports

  • Django

  • Mercurial

  • Bazaar

  • SQLAlchemy

The main issues appear to be:

• Integer division coerces to a float for non-integral values
  • Use int(x/y) instead of x/y when dividing integers
• Exceptions are a bit different
  • string exceptions are gone

  •       try:
            print(1/0)
          except:
            dummy, as_value, dummy = sys.exc_info()

• str -> bytes, unicode -> str

  • This one's a mess
  • This is a bit of an argument for moving to 3.x, and then using 3to2 - because it distinguishes between bytes and unicode better
• print function instead of statement
  • Use file_.write() instead of print
  • print(var1, var2) happens to work in Python 2, though it doesn't respect some of python 3's options.
    • This will probably surprise someone someday - it's no obvious that it's still the print statement in 2.x
• Some things that returned lists, now return iterators. Some things that returned iterators, are gone (or rather, renamed to what formerly returned a list). Example workaround:

  •     try:
          iter = d.iteritems()
        except AttributeError:
          iter = d.items()

• dict_.has_key(x) vs x in dict_

  •     try:
          dict_[x]
        except exceptions.AttributeError:
          # not in
        else:
          # in