Hi!, Ian! Thank you!
On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco
<graffatcolmin...@gmail.com> wrote:
> 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.
What's your Github login? I'll add you to the team.
> I'd love to hear everyone's feedback.
>
> Thanks,
> Ian
Oleg.
--
Oleg Broytman http://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
------------------------------------------------------------------------------
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
