sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

All tests are passed in branches 1.5, 1.6 and 1.7, and most tests are
passed in master; datetime test fails with MySQL:

   https://travis-ci.org/sqlobject/sqlobject/branches

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Thu, Dec 04, 2014 at 08:48:26AM -0600, Ian Cordasco <gra...@gm...> wrote:
> On Thu, Dec 4, 2014 at 8:39 AM, Oleg Broytman <ph...@ph...> wrote:
> >    Later we can change it. BTW, have you tried to run sqlobject's tests
> > with tox? I only run it with py.test.
> 
> I haven't tried it yet. Like I said in my first email, my time is kind
> of limited but I have this stuff on my TODO list. Currently this is
> what my GitHub notifications looks like though:
> http://i.imgur.com/LBcJnun.png (Most of those I actually have to work
> through and read (and maybe respond to))

   Well, I managed to run the tests on Travis. Tests with MySQL and
Postgres failed in datetime test (microseconds rounding); tests with
SQLite passed.
   Enough for now. I'm certainly no less busy at work.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

On Thu, Dec 4, 2014 at 8:39 AM, Oleg Broytman <ph...@ph...> wrote:
> On Thu, Dec 04, 2014 at 08:29:17AM -0600, Ian Cordasco <gra...@gm...> wrote:
>> So I tend to have a slightly more complex set-up anyway. (See:
>> https://github.com/sigmavirus24/github3.py/blob/develop/.travis.yml)
>> I've found it easier to do more nuanced Travis builds with tox and let
>> tox handle dependencies for the environment etc. (This also gives us
>> an easy way to run pyflakes without having to do weird things with the
>> travis.yml and gives contributors a way of having test environments
>> that should mirror the CI set-up really well with very minor deltas.)
>>
>> Now that Travis is enabled for the repository, I can fork your branch
>> with updates for this approach if you'd like.
>
>    Let me fix it in its current form. Now I need to install FormEncode.
>
>    Later we can change it. BTW, have you tried to run sqlobject's tests
> with tox? I only run it with py.test.
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            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=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

I haven't tried it yet. Like I said in my first email, my time is kind
of limited but I have this stuff on my TODO list. Currently this is
what my GitHub notifications looks like though:
http://i.imgur.com/LBcJnun.png (Most of those I actually have to work
through and read (and maybe respond to))

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Thu, Dec 04, 2014 at 08:29:17AM -0600, Ian Cordasco <gra...@gm...> wrote:
> So I tend to have a slightly more complex set-up anyway. (See:
> https://github.com/sigmavirus24/github3.py/blob/develop/.travis.yml)
> I've found it easier to do more nuanced Travis builds with tox and let
> tox handle dependencies for the environment etc. (This also gives us
> an easy way to run pyflakes without having to do weird things with the
> travis.yml and gives contributors a way of having test environments
> that should mirror the CI set-up really well with very minor deltas.)
> 
> Now that Travis is enabled for the repository, I can fork your branch
> with updates for this approach if you'd like.

   Let me fix it in its current form. Now I need to install FormEncode.

   Later we can change it. BTW, have you tried to run sqlobject's tests
with tox? I only run it with py.test.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Neil M. <drn...@gm...>]

On 4 December 2014 at 16:23, Oleg Broytman <ph...@ph...> wrote:
>> If you make a branch in the repository and (one of us [1]) enables
>> Travis then we can test the config to see how it works :)
>
>    Failed with error:
> /home/travis/build.sh: line 41: /usr/bin/py.test: No such file or directory
>    See https://travis-ci.org/sqlobject/sqlobject/
>
>    That's strange, docs say py.test is available:
> http://docs.travis-ci.com/user/ci-environment/
>    Preinstalled pip packages: nose py.test mock wheel.
>
>    Will try to install it...

Since it's described as being pip installed, my guess is that py.test
is in the virtualenv's bin directory, rather than /usr/bin.

-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

On Thu, Dec 4, 2014 at 8:23 AM, Oleg Broytman <ph...@ph...> wrote:
>> If you make a branch in the repository and (one of us [1]) enables
>> Travis then we can test the config to see how it works :)
>
>    Failed with error:
> /home/travis/build.sh: line 41: /usr/bin/py.test: No such file or directory
>    See https://travis-ci.org/sqlobject/sqlobject/
>
>    That's strange, docs say py.test is available:
> http://docs.travis-ci.com/user/ci-environment/
>    Preinstalled pip packages: nose py.test mock wheel.
>
>    Will try to install it...
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            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=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

So I tend to have a slightly more complex set-up anyway. (See:
https://github.com/sigmavirus24/github3.py/blob/develop/.travis.yml)
I've found it easier to do more nuanced Travis builds with tox and let
tox handle dependencies for the environment etc. (This also gives us
an easy way to run pyflakes without having to do weird things with the
travis.yml and gives contributors a way of having test environments
that should mirror the CI set-up really well with very minor deltas.)

Now that Travis is enabled for the repository, I can fork your branch
with updates for this approach if you'd like.

--
Ian

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

> If you make a branch in the repository and (one of us [1]) enables
> Travis then we can test the config to see how it works :)

   Failed with error:
/home/travis/build.sh: line 41: /usr/bin/py.test: No such file or directory
   See https://travis-ci.org/sqlobject/sqlobject/

   That's strange, docs say py.test is available:
http://docs.travis-ci.com/user/ci-environment/
   Preinstalled pip packages: nose py.test mock wheel.

   Will try to install it...

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

On Thu, Dec 4, 2014 at 12:13 AM, Oleg Broytman <ph...@ph...> wrote:
> Hi!
>
> On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
>> 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:
>
>    I have always wanted to learn Travis CI. See my first attempt at
> creating .travis.yml (attached).
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            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=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

If you make a branch in the repository and (one of us [1]) enables
Travis then we can test the config to see how it works :)

--
Ian

[1]: I'm not certain if I can modify settings on the repository or not
and haven't yet checked.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Thu, Dec 04, 2014 at 10:31:48AM +0200, Simon Cross <hod...@gm...> wrote:
> Travis runs Python builds inside a virtualenv for the selected Python
> version, with a few things pre-installed.

   Yes, got it. /usr/bin/python will be either python2.6 of 2.7. Thank
you for spotting!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Simon C. <hod...@gm...>]

Travis runs Python builds inside a virtualenv for the selected Python
version, with a few things pre-installed.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Hi!

On Thu, Dec 04, 2014 at 09:38:04AM +0200, Simon Cross <hod...@gm...> wrote:
> Looks good?
> 
> I was a bit surprised by the "/usr/bin/py.test-$TRAVIS_PYTHON_VERION".
> I would have thought that could just be "py.test"?

   But how do you run test with different python versions?

python:
  - "2.6"
  - "2.7"

   makes Travis to repeat the tests with different versions, so the test
script has either run

python-$TRAVIS_PYTHON_VERSION /usr/bin/py.test

   or

/usr/bin/py.test-$TRAVIS_PYTHON_VERSION

   At least that how I understand it. I am new to Travis.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Simon C. <hod...@gm...>]

Looks good?

I was a bit surprised by the "/usr/bin/py.test-$TRAVIS_PYTHON_VERION".
I would have thought that could just be "py.test"?

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Hi!

On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
> 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:

   I have always wanted to learn Travis CI. See my first attempt at
creating .travis.yml (attached).

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Tue, Dec 02, 2014 at 12:27:29AM +0200, Neil Muller <drn...@gm...> wrote:
> On 1 December 2014 at 22:49, Oleg Broytman <ph...@ph...> wrote:
> >
> >    What's your Github nick? I'll add you to the team.
> 
> Mine is drnlm

   Sent an invitation. Welcome on board!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Neil M. <drn...@gm...>]

On 1 December 2014 at 22:49, Oleg Broytman <ph...@ph...> wrote:
>
>    What's your Github nick? I'll add you to the team.

Mine is drnlm


-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

On Mon, Dec 01, 2014 at 02:58:20PM -0600, Ian Cordasco <gra...@gm...> wrote:
> >> 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.
> 
> sigmavirus24

   Sent an invitation. Welcome on board!

   I created a team called "developers" and gave it write access to
sqlobject/sqlobject repository. You'll be a member of the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

On Mon, Dec 1, 2014 at 2:47 PM, Oleg Broytman <ph...@ph...> wrote:
> Hi!, Ian! Thank you!
>

You're welcome! I derive immense joy from seeing awesome projects make
the leap, so I'm really happy to see people enthusiastic about this.

> On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> 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.

sigmavirus24

>
>> I'd love to hear everyone's feedback.
>>
>> Thanks,
>> Ian
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            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
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Hi!

On Mon, Dec 01, 2014 at 05:23:17PM +0200, Simon Cross <hod...@gm...> wrote:
> I'd also be interested in helping out.

   Tell me your Github nick, I'll add you to the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Hi!

On Mon, Dec 01, 2014 at 05:15:52PM +0200, Neil Muller <drn...@gm...> wrote:
> On 1 December 2014 at 16:53, Ian Cordasco <gra...@gm...> wrote:
> > Hey all,
> >
> > 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.
> 
> When I last looked (which was some time ago), formencode still didn't
> have a python 3 compatible release, but that appeared to be the only
> one still missing.

   Yes to both points.

> There's certainly interest in seeing sqlobject ported to python 3, and
> I would be willing to help as time allows.

   What's your Github nick? I'll add you to the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Oleg B. <ph...@ph...>]

Hi!, Ian! Thank you!

On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> 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/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Simon C. <hod...@gm...>]

I'd also be interested in helping out.

Re: [SQLObject] Proposed Plan for Porting to Python 3

[Neil M. <drn...@gm...>]

On 1 December 2014 at 16:53, Ian Cordasco <gra...@gm...> wrote:
> Hey all,
>
> 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.

When I last looked (which was some time ago), formencode still didn't
have a python 3 compatible release, but that appeared to be the only
one still missing.

Several of the less commonly used database backends don't have python
3 versions as far as I know. sqlite and postgresql should both be
fine, though. MySQL's status is a bit murky since the original MySQLdb
hasn't been ported to python 3 yet but there are a number of forks of
it claim to support python 3, so it's presumably doable.

> 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.

There's certainly interest in seeing sqlobject ported to python 3, and
I would be willing to help as time allows.

-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

[SQLObject] Proposed Plan for Porting to Python 3

[Ian C. <gra...@gm...>]

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

Re: [SQLObject] SQLObject and Py3

[Gustavo A. D. <gus...@gm...>]

Would be nice if I could have more time.

I just wanted to migrate my apps to Py3 but I am stil a newbie in Py3
changes :)

Cheers!

2014-10-30 15:38 GMT-03:00 Oleg Broytman <ph...@ph...>:

> Hi!
>
> On Thu, Oct 30, 2014 at 03:34:36PM -0300, "Gustavo A. D??az" <
> gus...@gm...> wrote:
> > Short question: SQLObject does not support Python V3 right?
>
>    Alas! Do you want to work on that?
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>



-- 

Gustavo A. Díaz

artistic.gdnet.com.ar

"Desarrollando un mundo Libre"

Re: [SQLObject] SQLObject and Py3

[Oleg B. <ph...@ph...>]

Hi!

On Thu, Oct 30, 2014 at 03:34:36PM -0300, "Gustavo A. D??az" <gus...@gm...> wrote:
> Short question: SQLObject does not support Python V3 right?

   Alas! Do you want to work on that?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.