sqlobject-discuss Mailing List for SQLObject (Page 23)

I'm stuck at a part of my program, but I'm not sure if this is the right
place to ask. Excuses if it's not.

I have a DVD object which can have different statusses, like "on loan",
"sold", etc... A dvd can only have 1 status at the time, but I'm confused
about how to link it to 1 table only so I can access the correct status
with dvd.status .

Here's an example:

class DVD(SQLObject):
    status = ???? # Should be sold or onloan data
    # ... special "dvd" data

class Sold(SQLObject):
    dvd = ForeignKey('DVD')
    # ... special "sold" data

class OnLoan(SQLObject):
    dvd = ForeignKey('DVD')
    # ... special "on loan" data

Greets,
Timo

Daniel & Oleg,

> > creating one .py file for each class, but it's turning out to be a mess 
> > of include statements.
> 
>    He-he, Python is not Java!

I was anticipating this response, but I did have good intentions when we set
out.  We are working on an application that will validate and export data from
an archaic accounting system with 16 years of patchwork and zero documentation.
 Because we have no idea how things relate to each other, we just created a
class for every table in the system and proceeded to work with them.  Overall,
it was a good refresher in Bad Python Coding Principles 101.  

In regards to the editor, seeing as how I'm on a windows machine, I've chosen to
install Eclipse and PyDev to help manage this project as UltraEdit just didn't
have the oomph to handle the sheer size of it all.






 

On 11 December 2011 17:22, Daniel Fetchinson <fet...@go...>wrote:

> > I need help managing my project files.  I've got over 120 class files
> > each that have their own specific validation routines.  Most of which
> > are pretty tame, but some are pretty nasty.  Anyways, I took a stab at a
> > creating one .py file for each class, but it's turning out to be a mess
> > of include statements.  Going back to a single file makes for a HUGE
> > file which is manageable, but annoying when searching for particular
> code.
> >
> > Anyways - I though I'd ask to see if there were any examples or
> > resources out there that I could look at that would help me clean this
> up.
>
>
As Oleg and Daniel suggest, using good IDE is the great advantage.
Personally, I am using Eric4 <http://eric-ide.python-projects.org/> which
is long time well supported and maintained.
You can maintain/manage the whole project. You can see all files for the
project. You can see all classes within each file. You can see all
attributes and functions if any. You can make string search through the all
files in the project .... and many many more.

Of course there are plenty of other IDE for
Python<http://wiki.python.org/moin/PythonEditors>
.

Cheers

Petr

> I need help managing my project files.  I've got over 120 class files
> each that have their own specific validation routines.  Most of which
> are pretty tame, but some are pretty nasty.  Anyways, I took a stab at a
> creating one .py file for each class, but it's turning out to be a mess
> of include statements.  Going back to a single file makes for a HUGE
> file which is manageable, but annoying when searching for particular code.
>
> Anyways - I though I'd ask to see if there were any examples or
> resources out there that I could look at that would help me clean this up.

Why not put around 10-20 classes that are closely related into one
file? This is what I do too, then you have around 10-15 files which is
manageable all right. Surely your classes can be grouped according to
some criteria.

Search and jumping around in source code is quite easy in vim which is
what I use, but I bet other good editors make it simple too. So
normally you don't have to search for strings but the function names,
class names, etc, are stored structurally in a 'tags' file which is
then used by the editor.

Cheers,
Daniel


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

Hi!

On Sat, Dec 10, 2011 at 02:47:44PM -0800, Glenn Rutkowski wrote:
> creating one .py file for each class, but it's turning out to be a mess 
> of include statements.

   He-he, Python is not Java!

> Going back to a single file makes for a HUGE 
> file which is manageable, but annoying when searching for particular code.

   You are choosing between two extreme solutions ("one class - one
file" and "all classes in one file") which IMHO are too extreme. Let me
advice to use something in between - use a few files. Put in one bed
things that naturally go together well, put in different files classes
that have no connection.

   Another advice would be to use pytags and a good IDE or at least an
editor that supports tags - that way you wouldn't spend much time
searching for names.

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

I need help managing my project files.  I've got over 120 class files 
each that have their own specific validation routines.  Most of which 
are pretty tame, but some are pretty nasty.  Anyways, I took a stab at a 
creating one .py file for each class, but it's turning out to be a mess 
of include statements.  Going back to a single file makes for a HUGE 
file which is manageable, but annoying when searching for particular code.

Anyways - I though I'd ask to see if there were any examples or 
resources out there that I could look at that would help me clean this up.

Thanks,

Glenn

Hello!

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


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:
http://pypi.python.org/pypi/SQLObject/1.2.1

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


What's New
==========

* A bug was fixed in handling ``modulo`` operator - SQLite implements
  only ``%``, MySQL - only ``MOD()``, PostgreSQL implements both.

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

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

Hello!

I'm pleased to announce version 1.1.4, a bugfix release of branch
1.1 of SQLObject.


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:
http://pypi.python.org/pypi/SQLObject/1.1.4

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


What's New
==========

* A bug was fixed in handling ``modulo`` operator - SQLite implements
  only ``%``, MySQL - only ``MOD()``, PostgreSQL implements both.

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

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

On Tue, Nov 22, 2011 at 11:22:30AM +0100, Daniel Fetchinson wrote:
> Now it worked for me as well, I don't know what happened, the first
> time it definitely installed 1.1.2, but now correctly it grabbed 1.2.

   The magic of PyPI.

> > PS. How things are going on with py3k?
> 
> I was working on formencode which more or less worked with py3k but
> haven't gotten around to touching sqlobject itself yet. I'll need to
> talk to Ian Bicking about merging my py3k branch of formencode but
> didn't have much time in the last couple of months. I'll try to
> complete this whole py3k thing as soon as I can.

   Ok, I see. Thank you.

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

>> Hi Oleg, is there a reason python 2.7 easy_install will fetch
>> sqlobject 1.1.2 but python 2.6 easy_install will find sqlobject 1.2?
>
>    Not for me. See:
>
> $ easy_install-2.7 -n SQLObject
> Searching for SQLObject
> Best match: SQLObject 1.2.0
> Processing SQLObject-1.2.0-py2.7.egg
>
> $ easy_install-2.7 -n -U SQLObject
> Searching for SQLObject
> Reading http://pypi.python.org/simple/SQLObject/
> Reading http://sqlobject.org
> Reading http://sqlobject.org/
> Reading http://sqlobject.org/devel/
> Best match: SQLObject 1.2.0
> Processing SQLObject-1.2.0-py2.7.egg
>
>    But I have installed 1.2.0 already.

Now it worked for me as well, I don't know what happened, the first
time it definitely installed 1.1.2, but now correctly it grabbed 1.2.

> PS. How things are going on with py3k?

I was working on formencode which more or less worked with py3k but
haven't gotten around to touching sqlobject itself yet. I'll need to
talk to Ian Bicking about merging my py3k branch of formencode but
didn't have much time in the last couple of months. I'll try to
complete this whole py3k thing as soon as I can.

Cheers,
Daniel


> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>


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

On Mon, Nov 21, 2011 at 07:34:55PM +0100, Daniel Fetchinson wrote:
> Hi Oleg, is there a reason python 2.7 easy_install will fetch
> sqlobject 1.1.2 but python 2.6 easy_install will find sqlobject 1.2?

   Not for me. See:

$ easy_install-2.7 -n SQLObject
Searching for SQLObject
Best match: SQLObject 1.2.0
Processing SQLObject-1.2.0-py2.7.egg

$ easy_install-2.7 -n -U SQLObject
Searching for SQLObject
Reading http://pypi.python.org/simple/SQLObject/
Reading http://sqlobject.org
Reading http://sqlobject.org/
Reading http://sqlobject.org/devel/
Best match: SQLObject 1.2.0
Processing SQLObject-1.2.0-py2.7.egg

   But I have installed 1.2.0 already.

PS. How things are going on with py3k?

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

Hi Oleg, is there a reason python 2.7 easy_install will fetch
sqlobject 1.1.2 but python 2.6 easy_install will find sqlobject 1.2?

Cheers,
Daniel


On 11/20/11, Oleg Broytman <ph...@ph...> wrote:
> Hello!
>
> I'm pleased to announce version 1.2.0, the first stable release of branch
> 1.2 of SQLObject.
>
>
> 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:
> http://pypi.python.org/pypi/SQLObject/1.2.0
>
> News and changes:
> http://sqlobject.org/News.html
>
>
> What's New
> ==========
>
> Features & Interface
> --------------------
>
> * Strings are treated specially in Select to allow
>   Select(['id, 'name'], where='value = 42'). Update allows a string in
>   WHERE.
>
> * ForeignKey('Table', refColumn='refcol_id') to allow ForeignKey to
>   point to a non-id column; the referred column must be a unique integer
>   column.
>
> * delColumn now accepts a ForeignKey's name without 'ID'.
>
> * Support for PostgreSQL 7.* is dropped. The minimal supported version of
>   PostgreSQL is 8.1 now.
>
> * Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
>   if the string contains characters escaped with backslash.
>
> * A bug caused by psycopg2 recently added a new boolean not callable
>   autocommit attribute was fixed.
>
> * sqlobject.__doc__ and main.__doc__ no longer contain version number.
>   Use sqlobject.version or version_info.
>
> For a more complete list, please see the news:
> http://sqlobject.org/News.html
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>


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

Hello!

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


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:
http://pypi.python.org/pypi/SQLObject/1.2.0

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


What's New
==========

Features & Interface
--------------------

* Strings are treated specially in Select to allow
  Select(['id, 'name'], where='value = 42'). Update allows a string in
  WHERE.

* ForeignKey('Table', refColumn='refcol_id') to allow ForeignKey to
  point to a non-id column; the referred column must be a unique integer
  column.

* delColumn now accepts a ForeignKey's name without 'ID'.

* Support for PostgreSQL 7.* is dropped. The minimal supported version of
  PostgreSQL is 8.1 now.

* Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
  if the string contains characters escaped with backslash.

* A bug caused by psycopg2 recently added a new boolean not callable
  autocommit attribute was fixed.

* sqlobject.__doc__ and main.__doc__ no longer contain version number.
  Use sqlobject.version or version_info.

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

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

Hello!

   I've added Python 2.7 to my development environment and just uploaded
SQLObject-1.2.0b1dev_r4477-py2.7.egg:

see https://pypi.python.org/pypi/SQLObject/1.2.0b1dev-r4477

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

On Sat, Nov 05, 2011 at 06:52:03PM +0400, Oleg Broytman wrote:
> * ForeignKey('Table', refColumn='refcol_id') to allow ForeignKey to
>   point to a non-id column; the referred column must be a unique integer
>   column.

   Consider this as an experimental feature. Use with care and test
thoroughly. Please note - MultipleJoin still uses `id` column.

> * Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
>   if the string contains characters escaped with backslash.

   Take care if you have your own objects that implement __sqlrepr__ -
if you have code like sqlrepr(obj)[1:-1] to remove quotes - it should be
written now as unqoute_str(sqlrepr(obj)). Code like "'%s'" % str should
be now quote_str(str).

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

Hello!

I'm pleased to announce version 1.2.0b1, the first beta of the upcoming
release of branch 1.2 of SQLObject.


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:
http://pypi.python.org/pypi/SQLObject/1.2.0b1dev-r4477

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


What's New
==========

Features & Interface
--------------------

* Strings are treated specially in Select to allow
  Select(['id, 'name'], where='value = 42'). Update allows a string in
  WHERE.

* ForeignKey('Table', refColumn='refcol_id') to allow ForeignKey to
  point to a non-id column; the referred column must be a unique integer
  column.

* delColumn now accepts a ForeignKey's name without 'ID'.

* Support for PostgreSQL 7.* is dropped. The minimal supported version of
  PostgreSQL is 8.1 now.

* Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
  if the string contains characters escaped with backslash.

* A bug caused by psycopg2 recently added a new boolean not callable
  autocommit attribute was fixed.

* sqlobject.__doc__ and main.__doc__ no longer contain version number.
  Use sqlobject.version or version_info.

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

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

I also did two commits fixing other minor problems with the script.

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

On Tue, Nov 01, 2011 at 03:59:23PM +0200, Neil Muller wrote:
> +export PYTHONPATH=$parent${PYTHONPATH:+:$PYTHONPATH}

   Applied and committed in the revision 4466 in the trunk. Will be in
version 1.2. Thank you! You can report to the Debian bug tracker the bug
is fixed upstream:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1RLg2r-0000jo-GB%40webwareforpython.org&forum_name=sqlobject-cvs

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

On Tue, Nov 01, 2011 at 06:07:39PM +0400, Oleg Broytman wrote:
> > +export PYTHONPATH=$parent${PYTHONPATH:+:$PYTHONPATH}
> 
>    Strange syntax ${PYTHONPATH:+:$PYTHONPATH} . Are you sure? Shouldn't
> it be just ${PYTHONPATH:+$PYTHONPATH} ?

   Ah, you want that ':' to be used with $PYTHONPATH -
$parent:$PYTHONPATH when $PYTHONPATH is not empty. I see now!

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

On Tue, Nov 01, 2011 at 04:31:43PM +0200, Neil Muller wrote:
> On 1 November 2011 16:07, Oleg Broytman <ph...@ph...> wrote:
> >   Strange syntax ${PYTHONPATH:+:$PYTHONPATH} . Are you sure? Shouldn't
> > it be just ${PYTHONPATH:+$PYTHONPATH} ?
> 
> It does look a little strange, but it is correct.
> 
> It's the POSIX shell alternate value syntax with ":$PYTHONPATH" as the
> alternate value. If the ':' is excluded,  there's no separator between
> $parent and $PYTHONPATH when PYTHONPATH is set, and the separator must
> only be added when PYTHONPATH is already set to fix the bug.

   Got it. Thank you!

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

On 1 November 2011 16:07, Oleg Broytman <ph...@ph...> wrote:
> On Tue, Nov 01, 2011 at 03:59:23PM +0200, Neil Muller wrote:
>> Debian currently has a bug against sqlobject for an insecure use of
>> PYTHONPATH in the docs/rebuild script -
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605185 . While it is
>> a minor issue, it's easy enough to do the right thing, so seems worth
>> fixing.
>>
>> Patch attached.
>>
>> --
>> Neil Muller
>> drn...@gm...
>
>   Thank you!
>
>> I've got a gmail account. Why haven't I become cool?
>
>> Index: docs/rebuild
>> ===================================================================
>> --- docs/rebuild      (revision 4465)
>> +++ docs/rebuild      (working copy)
>> @@ -3,7 +3,7 @@
>>  here=`pwd`
>>  parent=`dirname $here`
>>  echo "Adding $parent to \$PYTHONPATH"
>> -export PYTHONPATH=$parent:$PYTHONPATH
>> +export PYTHONPATH=$parent${PYTHONPATH:+:$PYTHONPATH}
>
>   Strange syntax ${PYTHONPATH:+:$PYTHONPATH} . Are you sure? Shouldn't
> it be just ${PYTHONPATH:+$PYTHONPATH} ?

It does look a little strange, but it is correct.

It's the POSIX shell alternate value syntax with ":$PYTHONPATH" as the
alternate value. If the ':' is excluded,  there's no separator between
$parent and $PYTHONPATH when PYTHONPATH is set, and the separator must
only be added when PYTHONPATH is already set to fix the bug.

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

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

On Tue, Nov 01, 2011 at 03:59:23PM +0200, Neil Muller wrote:
> Debian currently has a bug against sqlobject for an insecure use of
> PYTHONPATH in the docs/rebuild script -
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605185 . While it is
> a minor issue, it's easy enough to do the right thing, so seems worth
> fixing.
> 
> Patch attached.
> 
> -- 
> Neil Muller
> drn...@gm...

   Thank you!

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

> Index: docs/rebuild
> ===================================================================
> --- docs/rebuild	(revision 4465)
> +++ docs/rebuild	(working copy)
> @@ -3,7 +3,7 @@
>  here=`pwd`
>  parent=`dirname $here`
>  echo "Adding $parent to \$PYTHONPATH"
> -export PYTHONPATH=$parent:$PYTHONPATH
> +export PYTHONPATH=$parent${PYTHONPATH:+:$PYTHONPATH}

   Strange syntax ${PYTHONPATH:+:$PYTHONPATH} . Are you sure? Shouldn't
it be just ${PYTHONPATH:+$PYTHONPATH} ?

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

Hi!

On Tue, Nov 01, 2011 at 03:55:24PM +0200, Neil Muller wrote:
> Revision 4428 on trunk fixes a bug with psycog2's autocommit
> attribute, but, although committed in July, the fix didn't make it
> into 1.1.3 or the stable branch, AFAICS.
> 
> Would it be possible to get a 1.1.4 release including this fix?

   My opinion about the fix is that it's rather major change and I am a
bit nervous to include it into a minor release. It will be in SQLObject
1.2, I'm going to release the first beta this week.

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

   :-D

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

Debian currently has a bug against sqlobject for an insecure use of
PYTHONPATH in the docs/rebuild script -
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605185 . While it is
a minor issue, it's easy enough to do the right thing, so seems worth
fixing.

Patch attached.

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

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

Revision 4428 on trunk fixes a bug with psycog2's autocommit
attribute, but, although committed in July, the fix didn't make it
into 1.1.3 or the stable branch, AFAICS.

Would it be possible to get a 1.1.4 release including this fix?

Thanks.

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

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