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 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
