sqlobject-discuss — All things SQLObject-related

[SQLObject] SQLObject 1.7.1, 1.6.3, 1.5.5

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

Hello!

I'm pleased to announce versions 1.7.1, 1.6.3 and 1.5.5, documentation
update releases of SQLObject.


What's new in SQLObject
=======================

* Documentation update: change URLs for development with git, add
  Travis CI build status image.

* Extend sdist: include everything (even generated html)
  into source distribution.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.7.1
https://pypi.python.org/pypi/SQLObject/1.6.3
https://pypi.python.org/pypi/SQLObject/1.5.5

News and changes:
http://sqlobject.org/News.html

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

Re: [SQLObject] caching an expensive property

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

Hi!

On Thu, Dec 11, 2014 at 12:34:35AM +0100, "Fetchinson ." <fet...@go...> wrote:
> Hi Oleg, thanks again, this pushed me in the right direction and found
> 
> http://code.activestate.com/recipes/302997/

   Very interesting but overly complex for my taste.

> I'm not very good with SQL or
> SQLObject in particular

   Don't worry, I'm not good with them either! ;-)

> Thanks again,
> Daniel

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

Re: [SQLObject] caching an expensive property

[Fetchinson . <fet...@go...>]

On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
> On Wed, Dec 10, 2014 at 01:09:50AM +0100, "Fetchinson ."
> <fet...@go...> wrote:
>> On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
>> > you'd better implement your own
>> > caching with proper locking.
>>
>> Well, that was exactly the question, how would I do that? :)
>> Precisely for the reason you mention above I was wary of using a more
>> or less standard caching decorator. Can't I attach the computed value
>> to the instance itself somehow by setting a new property?
>
>    The classical approach is:
>
>     def __init__(self):
>         self.__cache = None
>         self.__cache_lock = Lock()
>
>     def _get_value(self):
>         if self.__cache is not None:
>             return self.__cache
>         self.__cache_lock.acquire()
>         try:
>             if self.__cache is not None: # Calculated in another thread
>                 return self.__cache
>             self.__cache = ...do expensive calculation once...
>             return self.__cache
>         finally: # finally works both for exceptions and returns
>             self.__cache_lock.release()

Hi Oleg, thanks again, this pushed me in the right direction and found

http://code.activestate.com/recipes/302997/

which is a pretty cool caching object including an implementation for
functions, just what I need. Now my application is a lot faster, in
some cases by a factor of 10 :)

Right now I'm happy with how things are, but I suspect that the
initial slowness was simply because I'm not very good with SQL or
SQLObject in particular and I'm not able to write the most optimal
queries. I guess I'll ask you about these things in a separate thread
:)

Thanks again,
Daniel


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


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] caching an expensive property

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

Hi!

On Wed, Dec 10, 2014 at 12:33:03AM +0000, Daniel Monteiro Basso <da...@ba...> wrote:
> For recent Python versions (>2.7 I guess), you could have also written like:
> with self.__cache_lock:
>     do_stuff
>     return self.__cache
> The context protocol takes care of the rest.

   Yes, in 2.6+.

> Cheers,
> Daniel

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

Re: [SQLObject] caching an expensive property

[Fetchinson . <fet...@go...>]

On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
> On Wed, Dec 10, 2014 at 01:09:50AM +0100, "Fetchinson ."
> <fet...@go...> wrote:
>> On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
>> > you'd better implement your own
>> > caching with proper locking.
>>
>> Well, that was exactly the question, how would I do that? :)
>> Precisely for the reason you mention above I was wary of using a more
>> or less standard caching decorator. Can't I attach the computed value
>> to the instance itself somehow by setting a new property?
>
>    The classical approach is:
>
>     def __init__(self):
>         self.__cache = None
>         self.__cache_lock = Lock()
>
>     def _get_value(self):
>         if self.__cache is not None:
>             return self.__cache
>         self.__cache_lock.acquire()
>         try:
>             if self.__cache is not None: # Calculated in another thread
>                 return self.__cache
>             self.__cache = ...do expensive calculation once...
>             return self.__cache
>         finally: # finally works both for exceptions and returns
>             self.__cache_lock.release()

Great, thanks a lot, this will get me started.

But I was thinking, maybe I'm doing things not in an optimal way: the
reason I thought about caching is that my expensive property really
takes a long time. I have 'collections' which can contain 'articles'
and 'articles' can be 'tagged'. So there is a many-to-many
relationship between 'articles' and 'tags' done by RelatedJoin in both
directions. What I'd like to have is for each 'collection' have a list
of [ ( 'tag1', 'number-of-articles' ), ( 'tag2', 'number-of-articles'
), ..... ] so for each 'collection' a list of all tags and the number
of articles associated with each tag. And for a collection of even
moderate size, let's say about 1000 articles and about 100 tags, this
take on the order of 2-3 seconds. This is my current approach:

class collection( SQLObject ):
    articles = MultipleJoin( 'article' )

class article( SQLObject ):
    tags = RelatedJoin( 'tag' )

class tag( SQLObject ):
    name = StringCol( )
    articles = RelatedJoin( 'article' )
    def _get_articlecount( self ):
        """Count number of articles with given tag."""
        # maybe this could be done better?
        return tag.select( tag.q.name == self.name ).throughTo.items.count( )

coll = collection.get( 1 )
# get list of all articles, then list of all distinct tags of all articles
# I guess this could be done also better?
tags = { }
for art in coll.articles:
    for tag in art.tags:
        tags[tag] = 1
tags = tags.keys( )
# the above is quite slow, but the following is slower still
# how could I speed this up?
result = [ ( tag, tag.articlecount ) for tag in tags ]


Cheers,
Daniel


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


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] caching an expensive property

[Daniel M. B. <da...@ba...>]

For recent Python versions (>2.7 I guess), you could have also written like:
with self.__cache_lock:
    do_stuff
    return self.__cache
The context protocol takes care of the rest.
Cheers,
Daniel

Re: [SQLObject] caching an expensive property

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

On Wed, Dec 10, 2014 at 01:09:50AM +0100, "Fetchinson ." <fet...@go...> wrote:
> On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
> > you'd better implement your own
> > caching with proper locking.
> 
> Well, that was exactly the question, how would I do that? :)
> Precisely for the reason you mention above I was wary of using a more
> or less standard caching decorator. Can't I attach the computed value
> to the instance itself somehow by setting a new property?

   The classical approach is:

    def __init__(self):
        self.__cache = None
        self.__cache_lock = Lock()

    def _get_value(self):
        if self.__cache is not None:
            return self.__cache
        self.__cache_lock.acquire()
        try:
            if self.__cache is not None: # Calculated in another thread
                return self.__cache
            self.__cache = ...do expensive calculation once...
            return self.__cache
        finally: # finally works both for exceptions and returns
            self.__cache_lock.release()

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

Re: [SQLObject] caching an expensive property

[Fetchinson . <fet...@go...>]

On 12/10/14, Oleg Broytman <ph...@ph...> wrote:
> Hi!
>
> On Wed, Dec 10, 2014 at 12:47:17AM +0100, "Fetchinson ."
> <fet...@go...> wrote:
>> What's the best strategy for some kind of caching of an expensive
>> property?
>>
>> Let's say I have the following:
>>
>> class obj( SQLObject ):
>>     somefield = StringCol( )
>>     someotherfield = StringCol( )
>>
>>     def _get_expensivestuff( self ):
>>         # takes a long time
>>         return result
>>
>> And if my obj instance is alive for a long time and expensivestuff
>> gets accessed many times I'd like to just compute result once, store
>> it somewhere (where?) and return it from there.
>>
>> I'm aware of memoizing the result of a function using a suitable
>> decorator but I'm concerned about thread safety and I'm not terribly
>> knowledgeable about the internals of sqlobject.
>>
>> Any ideas would help a lot. Thanks,
>> Daniel
>
>    I hope you know that SQLObject converts _get_* and _set_* methods to
> properties so you shouldn't decorate the methods.

Sure! I really like this feature of SQLObject.

> Also most caching
> decorators are not thread-safe so you'd better implement your own
> caching with proper locking.

Well, that was exactly the question, how would I do that? :)
Precisely for the reason you mention above I was wary of using a more
or less standard caching decorator. Can't I attach the computed value
to the instance itself somehow by setting a new property?

Cheers,
Daniel


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


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

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

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

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
> On Sun, Dec 07, 2014 at 08:06:29AM +0100, Oleg Broytman <ph...@ph...> wrote:
> >    MySQL doesn't support microseconds until 5.6.4, Travis runs
> > 5.5, so the error can be ignored.
> >    I will work on skipping the test on backends that don't support
> > microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> > be created with precision: TIME(6) instead of TIME and so on).
> 
>    Done, all tests are now passed, see
> https://travis-ci.org/sqlobject/sqlobject/branches

   BTW I added version test to MySQLConnection and test MariaDB >= 5.3.0
or MySQL >= 5.6.4.

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

Re: [SQLObject] caching an expensive property

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

Hi!

On Wed, Dec 10, 2014 at 12:47:17AM +0100, "Fetchinson ." <fet...@go...> wrote:
> What's the best strategy for some kind of caching of an expensive property?
> 
> Let's say I have the following:
> 
> class obj( SQLObject ):
>     somefield = StringCol( )
>     someotherfield = StringCol( )
> 
>     def _get_expensivestuff( self ):
>         # takes a long time
>         return result
> 
> And if my obj instance is alive for a long time and expensivestuff
> gets accessed many times I'd like to just compute result once, store
> it somewhere (where?) and return it from there.
> 
> I'm aware of memoizing the result of a function using a suitable
> decorator but I'm concerned about thread safety and I'm not terribly
> knowledgeable about the internals of sqlobject.
> 
> Any ideas would help a lot. Thanks,
> Daniel

   I hope you know that SQLObject converts _get_* and _set_* methods to
properties so you shouldn't decorate the methods. Also most caching
decorators are not thread-safe so you'd better implement your own
caching with proper locking.

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 Sun, Dec 07, 2014 at 08:06:29AM +0100, Oleg Broytman <ph...@ph...> wrote:
>    MySQL doesn't support microseconds until 5.6.4, Travis runs
> 5.5, so the error can be ignored.
>    I will work on skipping the test on backends that don't support
> microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> be created with precision: TIME(6) instead of TIME and so on).

   Done, all tests are now passed, see
https://travis-ci.org/sqlobject/sqlobject/branches

   I added the test status images at PyPI, see
https://pypi.python.org/pypi/SQLObject/1.5.4
https://pypi.python.org/pypi/SQLObject/1.6.2
https://pypi.python.org/pypi/SQLObject/1.7.0
https://pypi.python.org/pypi/SQLObject/2.0.0a2dev-20141028
   Need to add them to the docs.

   There is one sporadic bug related to round number of microseconds
like 83500: some parts of code think it's 0.0835 (83500), and some think
it's 0.835 (835000). See the traceback near the end of
https://travis-ci.org/sqlobject/sqlobject/jobs/42989776
   I hope to fix the bug. Then I'm going to release 2.0 beta 1 and
create a separate branch for 2.0. Then master will be free for working
on Py3 compatibility.

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

[SQLObject] caching an expensive property

[Fetchinson . <fet...@go...>]

What's the best strategy for some kind of caching of an expensive property?

Let's say I have the following:

class obj( SQLObject ):
    somefield = StringCol( )
    someotherfield = StringCol( )

    def _get_expensivestuff( self ):
        # takes a long time
        return result

And if my obj instance is alive for a long time and expensivestuff
gets accessed many times I'd like to just compute result once, store
it somewhere (where?) and return it from there.

I'm aware of memoizing the result of a function using a suitable
decorator but I'm concerned about thread safety and I'm not terribly
knowledgeable about the internals of sqlobject.

Any ideas would help a lot. Thanks,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

[SQLObject] SQLObject 1.7.0

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

Hello!

I'm pleased to announce version 1.7.0, the first stable release of branch
1.7 of SQLObject.


What's new in SQLObject
=======================

* Python 2.5 is no longer supported. The minimal supported version is
  Python 2.6.

* DateTimeCol and TimeCol can read values with microseconds (created by
  SQLObject 2.0) but do not write microseconds back.

* Upgrade ez_setup to 2.2.

* Adapt duplicate error message strings for SQLite 3.8.

* Allow unicode in .orderBy(u'-column').

* Fix a minor bug in MSSQLConnection: do not override callable server_version
  with a non-callable.

Contributors for this release are Geoffrey Wossum, Neil Muller and
Andrew Trusty.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.7.0

News and changes:
http://sqlobject.org/News.html

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

[SQLObject] SQLObject 1.6.2

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

Hello!

I'm pleased to announce version 1.6.2, a bugfix release of branch
1.6 of SQLObject.


What's new in SQLObject
=======================

* Fix a minor bug in MSSQLConnection: do not override callable server_version
  with a non-callable.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.6.2

News and changes:
http://sqlobject.org/News.html

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

[SQLObject] SQLObject 1.5.4

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

Hello!

I'm pleased to announce version 1.5.4, a bugfix release of branch
1.5 of SQLObject.


What's new in SQLObject
=======================

* Fix a minor bug in MSSQLConnection: do not override callable server_version
  with a non-callable.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.5.4

News and changes:
http://sqlobject.org/News.html

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

Not sure about completeness but at least there is something to test.

On Mon, Dec 08, 2014 at 02:53:14PM +0100, "Fetchinson ." <fet...@go...> wrote:
> On 12/8/14, Oleg Broytman <ph...@ph...> wrote:
> > The new maintainers of FormEncode promised compatibility of version 1.3
> > with Py3: http://www.formencode.org/en/latest/whatsnew-1.3.html
> >    They released the first alpha a year ago:
> > https://pypi.python.org/pypi/FormEncode and it seems there are commits
> > in the repository since that: https://github.com/formencode/formencode
> 
> Great, I was not aware of that, then at least the formencode part is
> complete now.
> 
> Cheers,
> Daniel
> 
> 
> > On Mon, Dec 08, 2014 at 11:54:00AM +0100, "Fetchinson ."
> > <fet...@go...> wrote:
> >> Hi all, I've started a python 3 branch of formencde in 2011 but didn't
> >> have time to finish a complete port, you might still find it useful:
> >>
> >> https://bitbucket.org/fetchinson/formencode-py3k
> >>
> >> To be precise, this is still a python 2 branch, the goal was to have
> >> something which can be fed into 2to3, at the current point there are
> >> still 2 errors and 3 failures though when the output of 2to3 is
> >> tested. This was my working cycle:
> >>
> >>
> >>
> >> #!/bin/bash
> >>
> >> rm -rf formencode-py3k-2to3.hg
> >> cp -r formencode-py3k.hg formencode-py3k-2to3.hg
> >> find formencode-py3k-2to3.hg -name .*.swp -exec rm {} ';'
> >> /path/to/2to3 formencode-py3k-2to3.hg -w
> >> cd formencode-py3k-2to3.hg
> >> python3.2 -c "import nose;nose.run_exit()" > ../out 2>&1
> >> cd ..
> >> vim out
> >>
> >> If I remember correctly all the errors are unicode related. In any
> >> case I also think the best way is to have a single code base which
> >> works with python 2 but which also translates smoothly by 2to3. So the
> >> python 3 version can always be obtained by running 2to3 on the single
> >> code base.
> >>
> >> Hope you find it useful!
> >> Daniel

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

[Fetchinson . <fet...@go...>]

On 12/8/14, Oleg Broytman <ph...@ph...> wrote:
> The new maintainers of FormEncode promised compatibility of version 1.3
> with Py3: http://www.formencode.org/en/latest/whatsnew-1.3.html
>    They released the first alpha a year ago:
> https://pypi.python.org/pypi/FormEncode and it seems there are commits
> in the repository since that: https://github.com/formencode/formencode

Great, I was not aware of that, then at least the formencode part is
complete now.

Cheers,
Daniel


> On Mon, Dec 08, 2014 at 11:54:00AM +0100, "Fetchinson ."
> <fet...@go...> wrote:
>> Hi all, I've started a python 3 branch of formencde in 2011 but didn't
>> have time to finish a complete port, you might still find it useful:
>>
>> https://bitbucket.org/fetchinson/formencode-py3k
>>
>> To be precise, this is still a python 2 branch, the goal was to have
>> something which can be fed into 2to3, at the current point there are
>> still 2 errors and 3 failures though when the output of 2to3 is
>> tested. This was my working cycle:
>>
>>
>>
>> #!/bin/bash
>>
>> rm -rf formencode-py3k-2to3.hg
>> cp -r formencode-py3k.hg formencode-py3k-2to3.hg
>> find formencode-py3k-2to3.hg -name .*.swp -exec rm {} ';'
>> /path/to/2to3 formencode-py3k-2to3.hg -w
>> cd formencode-py3k-2to3.hg
>> python3.2 -c "import nose;nose.run_exit()" > ../out 2>&1
>> cd ..
>> vim out
>>
>> If I remember correctly all the errors are unicode related. In any
>> case I also think the best way is to have a single code base which
>> works with python 2 but which also translates smoothly by 2to3. So the
>> python 3 version can always be obtained by running 2to3 on the single
>> code base.
>>
>> Hope you find it useful!
>> Daniel
>
> 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
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

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

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

The new maintainers of FormEncode promised compatibility of version 1.3
with Py3: http://www.formencode.org/en/latest/whatsnew-1.3.html
   They released the first alpha a year ago:
https://pypi.python.org/pypi/FormEncode and it seems there are commits
in the repository since that: https://github.com/formencode/formencode

On Mon, Dec 08, 2014 at 11:54:00AM +0100, "Fetchinson ." <fet...@go...> wrote:
> Hi all, I've started a python 3 branch of formencde in 2011 but didn't
> have time to finish a complete port, you might still find it useful:
> 
> https://bitbucket.org/fetchinson/formencode-py3k
> 
> To be precise, this is still a python 2 branch, the goal was to have
> something which can be fed into 2to3, at the current point there are
> still 2 errors and 3 failures though when the output of 2to3 is
> tested. This was my working cycle:
> 
> 
> 
> #!/bin/bash
> 
> rm -rf formencode-py3k-2to3.hg
> cp -r formencode-py3k.hg formencode-py3k-2to3.hg
> find formencode-py3k-2to3.hg -name .*.swp -exec rm {} ';'
> /path/to/2to3 formencode-py3k-2to3.hg -w
> cd formencode-py3k-2to3.hg
> python3.2 -c "import nose;nose.run_exit()" > ../out 2>&1
> cd ..
> vim out
> 
> If I remember correctly all the errors are unicode related. In any
> case I also think the best way is to have a single code base which
> works with python 2 but which also translates smoothly by 2to3. So the
> python 3 version can always be obtained by running 2to3 on the single
> code base.
> 
> Hope you find it useful!
> Daniel

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

[Fetchinson . <fet...@go...>]

Hi all, I've started a python 3 branch of formencde in 2011 but didn't
have time to finish a complete port, you might still find it useful:

https://bitbucket.org/fetchinson/formencode-py3k

To be precise, this is still a python 2 branch, the goal was to have
something which can be fed into 2to3, at the current point there are
still 2 errors and 3 failures though when the output of 2to3 is
tested. This was my working cycle:



#!/bin/bash

rm -rf formencode-py3k-2to3.hg
cp -r formencode-py3k.hg formencode-py3k-2to3.hg
find formencode-py3k-2to3.hg -name .*.swp -exec rm {} ';'
/path/to/2to3 formencode-py3k-2to3.hg -w
cd formencode-py3k-2to3.hg
python3.2 -c "import nose;nose.run_exit()" > ../out 2>&1
cd ..
vim out

If I remember correctly all the errors are unicode related. In any
case I also think the best way is to have a single code base which
works with python 2 but which also translates smoothly by 2to3. So the
python 3 version can always be obtained by running 2to3 on the single
code base.

Hope you find it useful!
Daniel


On 12/8/14, Oleg Broytman <ph...@ph...> wrote:
> On Mon, Dec 08, 2014 at 02:01:22AM +0100, Oleg Broytman <ph...@ph...>
> wrote:
>> http://docs.travis-ci.com/user/installing-dependencies/
>
>    But that doesn't help: Travis runs Ubuntu 12.04 (see
> http://docs.travis-ci.com/user/ci-environment/) and it only has MySQL 5.5:
> http://packages.ubuntu.com/search?keywords=mysql&searchon=names&suite=precise&section=all
>
> 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
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

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

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

On Mon, Dec 08, 2014 at 02:01:22AM +0100, Oleg Broytman <ph...@ph...> wrote:
> http://docs.travis-ci.com/user/installing-dependencies/

   But that doesn't help: Travis runs Ubuntu 12.04 (see
http://docs.travis-ci.com/user/ci-environment/) and it only has MySQL 5.5:
http://packages.ubuntu.com/search?keywords=mysql&searchon=names&suite=precise&section=all

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 Sun, Dec 07, 2014 at 12:10:16PM -0600, Ian Cordasco <gra...@gm...> wrote:
> On Sun, Dec 7, 2014 at 1:06 AM, Oleg Broytman <ph...@ph...> wrote:
> > On Fri, Dec 05, 2014 at 08:38:31PM +0100, Oleg Broytman <ph...@ph...> wrote:
> >> datetime test fails with MySQL:
> >
> >    Got it: MySQL doesn't support microseconds until 5.6.4, Travis runs
> > 5.5, so the error can be ignored.
> >    I will work on skipping the test on backends that don't support
> > microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> > be created with precision: TIME(6) instead of TIME and so on).
> 
> I think you can use apt (e.g., apt-get, apt-cache, etc.) on Travis and
> you can probably upgrade it to the version of MySQL that you would
> like to test against.

   I'd certainly like to test against both old and new versions.

> I'm  having trouble finding it in the docs though so I'll have to see
> if I can find other projects that do this.

   Something like this:
http://docs.travis-ci.com/user/installing-dependencies/
   ?

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 Sun, Dec 7, 2014 at 1:06 AM, Oleg Broytman <ph...@ph...> wrote:
> On Fri, Dec 05, 2014 at 08:38:31PM +0100, Oleg Broytman <ph...@ph...> wrote:
>> datetime test fails with MySQL:
>
>    Got it: MySQL doesn't support microseconds until 5.6.4, Travis runs
> 5.5, so the error can be ignored.
>    I will work on skipping the test on backends that don't support
> microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> be created with precision: TIME(6) instead of TIME and so on).

I think you can use apt (e.g., apt-get, apt-cache, etc.) on Travis and
you can probably upgrade it to the version of MySQL that you would
like to test against.

I'm  having trouble finding it in the docs though so I'll have to see
if I can find other projects that do this.

> 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

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

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

On Fri, Dec 05, 2014 at 08:38:31PM +0100, Oleg Broytman <ph...@ph...> wrote:
> datetime test fails with MySQL:

   Got it: MySQL doesn't support microseconds until 5.6.4, Travis runs
5.5, so the error can be ignored.
   I will work on skipping the test on backends that don't support
microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
be created with precision: TIME(6) instead of TIME and so on).

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

   Support for Python 2.5 will be dropped with the final release of
SQLObject 1.7.0 (the second beta was released).

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

Woot.