[SQLObject] Proposed Plan for Porting to Python 3

Hey all,

I see there's been some discussion of late about porting the library
to support Python 3. I'm a *very occasional* user of SQLObject and
I've not contributed thus far, but I have some experience porting
code-bases to support Python 3. The following is the sum of my
experiences and is by no means absolute fact or the experiences of
others.

I'm personally of the opinion that having separate branches for Python
2 and Python 3 is a really bad idea. It works for some but it is way
too much overhead and it always ends up in something getting out of
sync. The best way forward is to have one codebase that works on
Python 2 and Python 3.

First, I've found it far easier to support Python 3 once Python 2.5
support has been dropped. It is possible to support Python 2.5 (pep8,
pyflakes, mccabe, and flake8 are all projects which do this) but it is
tricky. It would be up to the community whether it wants to support
2.5 or not and I really don't feel right in telling you to drop
support for it altogether (although planning that may be a good idea).

Second, a strategy that Alex Gaynor uses is to run flake8 under python
2 and python 3. A quick look at SQLObject's source makes me believe
this is suboptimal at this point. The code mostly complies with pep8
but would still have a lot of extraneous output generated by the pep8
tool that flake8 uses. The reason for using flake8 is that pyflakes
(which flake8 uses) compiles the code using the AST and when
compilation fails, it tells you for which file(s) it failed and where.
This will help us simply make the code *run* on Python 3.

Third, setting up a continuous integration system (like Travis CI) to
run the tests after every push and whenever someone submits a pull
request. The CI system can do the following:

- Run the tests on a specified version of Python (usually limited to
things like 2.6, 2.7, 3.2, 3.3, 3.4, pypy, etc. and not allowing for
granularity like 2.6.8 and 2.6.9)
- Run pyflakes (or flake8) on specified versions of Python
- Generating docs and ensuring they build properly
- Other goodies

This helps us catch regressions in Python 3 support or Python 2 support.

Fourth, using a library like six to help cover some common import or
string related problems in supporting Python 2 and 3 in a single
codebase.

~~

This is of course all predicated on the assumption that sqlobject's
dependencies support Python 3 as well, but I haven't looked into all
of them. It also is predicated on sqlobject wanting to wait (or not
wait) for those dependencies before adding support.

I've sent this email to see if I'm the only one interested in helping
with the "port". I definitely don't have the time to do this all by
myself and having about 4 or more people to help would be amazing.

Personally, I prefer working on GitHub if possible and I know the
repository is already there. I would be happy to help coordinate and
review pull requests there if people can help with this.

I'd love to hear everyone's feedback.

Thanks,
Ian