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
    - A lot of this can be removed, with the planned cessation of CPython 2.4 support
  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 five ways Dan's encountered so far:
  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.
  5. Use 2to3 via SQLAlchemy's sa2to3 wrapper to preprocess things for python2 or python3.
- The owners of the code prefer methods #1 and #2 over #3 above; we've not yet discussed methods 4 or 5.
- 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

Includes a "sa2to3" script that allows you to do things like the following to get unified code, in a limited sense, for python2 and python3:

      except Exception, e:
        # Py3K
        #raise exc.DBAPIError.instance(None, None, e) from e
        # Py2K
        import sys
        raise exc.DBAPIError.instance(None, None, e), None, sys.exc_info()[2]
        # end Py2K

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

Details

Working with the SCM

There's a mercurial cheat sheet at: http://mercurial.selenic.com/wiki/QuickReferenceCardsAndCheatSheets
You can get the sources with:
- hg clone http://www.logilab.org/hg/pylint
- hg clone http://www.logilab.org/src/logilab/astng
- hg clone http://www.logilab.org/src/logilab/common
You can do "local commits" of your changes

Running the tests

With an install
- Install common via the usual setup.py methods
- You can run the tests with something like:
  - ```
    cd common
    rm -rf build
    /usr/local/cpython-2.5/bin/python2.5 /usr/local/bin/pytest
```
Without an install (this does not fully work! It uses a pre-install script with installed modules)
- Run the tests with:
  - ```
    cd common
    rm -rf build
    /usr/local/cpython-2.5/bin/python2.5 bin/pytest
```
Don't worry (yet) about the mxDateTime stuff failing. There doesn't appear to be a py3k port of mxDateTime, and I'm told we shouldn't need it (right away?)

Notes on logilab-common

The logilab.common.compat module is the main interface for

handling with different Python versions. This is also to be used for astng / pylint. Until now, it could be avoided to use sa2to3.

Most of the work for making logilab-common Py3k compatible is done. With the current work, and after running 2to3, one can use Pytest or

at least:

```
  python test/unittest_something.py
```

Pytest and testlib.py do not always work as they should, but

nevertheless can be used for running the astng/pylint tests.

Notes on Astng

We will have to implement 5-6 extra node classes with their methods;

and some 'visit_<node_name>' methods for the visitors in Astng.

Page

User