sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] datetime column conversions

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

On Thu, Jan 06, 2005 at 12:51:14PM -0200, Carlos Ribeiro wrote:
> On Thu, 6 Jan 2005 17:28:52 +0300, Oleg Broytmann <ph...@ma...> wrote:
> >    SQLObject does not keep an internal representation. It keeps
> > pythonic values, and convert them upon reading/writing fron/to DB. So,
> > fromPython is your toDB, and toPython is fromDB.
> 
> In fact, SQLObject does maintain an internal representation. It has a
> optional cache to accelerate data access (see the calls to
> "setattr(self, instanceName(name), value)").

   It keeps just the value, a Pythonic value. It returns it on read
and converts to database format on write.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Re: Re: datetime column conversions

[Ian B. <ia...@co...>]

Jorge Luiz Godoy Filho wrote:
>>I'm confused about it. AFAIK, SQLObject sits in the middle of the way:
>>
>>    Python code <-> SQLObject <-> DB Driver
>>
>>I assume that the toPython & fromPython methods are supposed to be
>>used in the interface between Python code & SQLObject. Using the same
>>functions for the interface between SQLObject & DB driver seems kind
>>of weird. Wouldn't it be better to have an equivalent pair of toDB &
>>fromDB methods?
> 
> 
> Isn't it "fromPython -> toDB" and "toPython -> fromDB"?  I didn't think it
> was between <something> and SQLObject, but the glue between the DB and
> Python done by SQLObject directly.

Just to clarify, this is correct...

Database -> Python = toPython
Python -> Database = fromPython

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Re: Re: Re: datetime column conversions

[Ian B. <ia...@co...>]

Jorge Luiz Godoy Filho wrote:
> Oleg Broytmann, Quinta 06 Janeiro 2005 09:19, wrote:
> 
> 
>>   You can wrap both fromPython and toPython.
> 
> 
> Simultaneously?

Yes, that's the point of using validator objects instead of two 
independent conversion functions, because generally a transformation to 
the database has a corresponding transformation coming from the 
database.  (Not always; e.g., when the driver does the transformation 
from the database)

By putting them together, chaining them becomes a bit safer as well, 
since it's clearer what order they should be applied in.  Honestly, that 
kind of chaining won't happen a whole lot in SQLObject, but in other 
situations it can.  I've considered making these hooks easier to write, 
including the _set_columnName hooks.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Re: Re: datetime column conversions

[Carlos R. <car...@gm...>]

On Thu, 6 Jan 2005 17:28:52 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Thu, Jan 06, 2005 at 09:29:52AM -0200, Carlos Ribeiro wrote:
> > I'm confused about it. AFAIK, SQLObject sits in the middle of the way:
> >
> >     Python code <-> SQLObject <-> DB Driver
> >
> > I assume that the toPython & fromPython methods are supposed to be
> > used in the interface between Python code & SQLObject. Using the same
> > functions for the interface between SQLObject & DB driver seems kind
> > of weird. Wouldn't it be better to have an equivalent pair of toDB &
> > fromDB methods?
> 
>    SQLObject does not keep an internal representation. It keeps
> pythonic values, and convert them upon reading/writing fron/to DB. So,
> fromPython is your toDB, and toPython is fromDB.

In fact, SQLObject does maintain an internal representation. It has a
optional cache to accelerate data access (see the calls to
"setattr(self, instanceName(name), value)"). Also, on creation, it
needs to store all data to do a single insert; and if _lazyUpdate is
set, it also keeps the values in a local cache (ex: _SO_setValue on
main.py).

I really miss not being able to take some time to study SQLObject
internals in depth right now. My gut feeling is that the architecture
could be simplified by cleanly separating the roles (toPython &
fromPython + toDB & fromDB), but I can't prove myself right now.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] datetime column conversions

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

On Wed, Jan 05, 2005 at 11:21:09PM -0600, Ian Bicking wrote:
> DateTimeCol.setDefaultImplementation().  In fact, it's just as good if 
> it takes a string to indicate which implementation, since their 
> interfaces are sufficiently different that you can't deal with the 
> module in any abstract way.

   That's why I thought I'd need two different classes.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Re: datetime column conversions

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

On Thu, Jan 06, 2005 at 09:29:52AM -0200, Carlos Ribeiro wrote:
> I'm confused about it. AFAIK, SQLObject sits in the middle of the way:
> 
>     Python code <-> SQLObject <-> DB Driver
> 
> I assume that the toPython & fromPython methods are supposed to be
> used in the interface between Python code & SQLObject. Using the same
> functions for the interface between SQLObject & DB driver seems kind
> of weird. Wouldn't it be better to have an equivalent pair of toDB &
> fromDB methods?

   SQLObject does not keep an internal representation. It keeps
pythonic values, and convert them upon reading/writing fron/to DB. So,
fromPython is your toDB, and toPython is fromDB.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: Re: Re: datetime column conversions

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

On Thu, Jan 06, 2005 at 10:02:32AM -0200, Jorge Luiz Godoy Filho wrote:
> Oleg Broytmann, Quinta 06 Janeiro 2005 09:19, wrote:
> 
> >    You can wrap both fromPython and toPython.
> 
> Simultaneously?

   Yes. Read validators.py, class Wrap.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Re: Re: Re: datetime column conversions

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Quinta 06 Janeiro 2005 09:19, wrote:

>    You can wrap both fromPython and toPython.

Simultaneously?

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] Re: Re: Re: datetime column conversions

[Carlos R. <car...@gm...>]

On Thu, 06 Jan 2005 10:02:21 -0200, Jorge Luiz Godoy Filho
<go...@ie...> wrote:
> Carlos Ribeiro, Quinta 06 Janeiro 2005 09:29, wrote:
> 
> > I'm confused about it. AFAIK, SQLObject sits in the middle of the way:
> >
> >     Python code <-> SQLObject <-> DB Driver
> >
> > I assume that the toPython & fromPython methods are supposed to be
> > used in the interface between Python code & SQLObject. Using the same
> > functions for the interface between SQLObject & DB driver seems kind
> > of weird. Wouldn't it be better to have an equivalent pair of toDB &
> > fromDB methods?
> 
> Isn't it "fromPython -> toDB" and "toPython -> fromDB"?  I didn't think it
> was between <something> and SQLObject, but the glue between the DB and
> Python done by SQLObject directly.

I think I have mixed the issues somewhat. I'm re-reading SQLObject
code right now. The reason for my confusion is the fact that I'm sure
I've seen fromPython & toPython being used in both situations. At this
point I'm not sure about what was the original design intention, or
even if this point was ever raised.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Re: On Postel's Law, or: why should SQLObject automatically coerce values on database read

[Jorge L. G. F. <go...@ie...>]

Carlos Ribeiro, Quinta 06 Janeiro 2005 09:11, wrote:

> I'm sorry. There was really some misunderstanding. I really thought
> that you were *opposed* to it - specifically, in the IntCol() case,

I thought the same... 

-- 
Godoy.     <go...@ie...>

[SQLObject] Re: Re: Re: datetime column conversions

[Jorge L. G. F. <go...@ie...>]

Carlos Ribeiro, Quinta 06 Janeiro 2005 09:29, wrote:

 
> I'm confused about it. AFAIK, SQLObject sits in the middle of the way:
> 
>     Python code <-> SQLObject <-> DB Driver
> 
> I assume that the toPython & fromPython methods are supposed to be
> used in the interface between Python code & SQLObject. Using the same
> functions for the interface between SQLObject & DB driver seems kind
> of weird. Wouldn't it be better to have an equivalent pair of toDB &
> fromDB methods?

Isn't it "fromPython -> toDB" and "toPython -> fromDB"?  I didn't think it
was between <something> and SQLObject, but the glue between the DB and
Python done by SQLObject directly.
 

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] Re: Re: datetime column conversions

[Carlos R. <car...@gm...>]

On Thu, 6 Jan 2005 14:19:41 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Thu, Jan 06, 2005 at 08:28:12AM -0200, Jorge Luiz Godoy Filho wrote:
> > > class Converting(SQLObject):
> > >     age = IntCol(validator=validators.Wrapper(fromPython=int),
> > >     default=100)
> >
> > I have to check the docs on this, but from "intuition", shouldn't it be
> > "toPython", since the data is coming from the Database?
> 
>    You can wrap both fromPython and toPython.

I'm confused about it. AFAIK, SQLObject sits in the middle of the way:

    Python code <-> SQLObject <-> DB Driver

I assume that the toPython & fromPython methods are supposed to be
used in the interface between Python code & SQLObject. Using the same
functions for the interface between SQLObject & DB driver seems kind
of weird. Wouldn't it be better to have an equivalent pair of toDB &
fromDB methods?

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Re: Re: datetime column conversions

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

On Thu, Jan 06, 2005 at 08:28:12AM -0200, Jorge Luiz Godoy Filho wrote:
> > class Converting(SQLObject):
> >     age = IntCol(validator=validators.Wrapper(fromPython=int),
> >     default=100)
> 
> I have to check the docs on this, but from "intuition", shouldn't it be
> "toPython", since the data is coming from the Database?

   You can wrap both fromPython and toPython.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] On Postel's Law, or: why should SQLObject automatically coerce values on database read

[Carlos R. <car...@gm...>]

On Thu, 6 Jan 2005 13:19:54 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Thu, Jan 06, 2005 at 07:57:34AM -0200, Carlos Ribeiro wrote:
> > SQLObject should perform automatic coercion on all the data it fetches
> > from the database.
> 
>    There is a big misunderstanding between you and me. I have no
> objection for conversion from DB to Python. All my objections were about
> Python-to-DB conversion.

I'm sorry. There was really some misunderstanding. I really thought
that you were *opposed* to it - specifically, in the IntCol() case,
opposed to coercing the data as int() on read. Also, I believe that's
not a job for the validator. More than that, I was afraid that as a
general principle, SQLObject would try to be "strict" when reading
external data. For instance, that would prevent SQLObject from working
with any naturally "typeless" data storage system - CSV files, for
example, where everything is read as a string and has to be coerced to
the correct type on read.

>    If a column .age is the IntCol, I don't want to see the code
> atable.age = '1'
>    The code must raise TypeError or InvalidField exception. Those who
> want such code in their programs will implemet the conversion
> themselves and take all responsibility for it.

Agreed.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] datetime column conversions

[Max I. <ma...@uc...>]

Oleg Broytmann wrote:

>>register a coersion method, as Carlos suggests.
> 
> 
> class Converting(SQLObject):
>     age = IntCol(validator=validators.Wrapper(fromPython=int), default=100)

That's great.

But why not:
  class Converting(SQLObject):
      age = IntCol(toPython=int, default=100)

Yes, it's just a shortcut but it streamlines an API.
Another use case. Here is my current version to plug-in my own currency 
type:

class CurrencyMoneyValidator(validators.Validator):

     def fromPython(self, value, state):
         if isinstance(value, Money):
             return value.getValue()
         return value
     def toPython(self, value, state):
         if isinstance(value, float):
             return Money(value=value)
         return value

class SOMoneyCol(SOCurrencyCol):

     def __init__(self, **kw):
         SOCurrencyCol.__init__(self, **kw)
         self.validator = validators.All.join(
             CurrencyMoneyValidator(), self.validator)

class MoneyCol(Col):
     baseClass = SOMoneyCol


IMO, it's clumsy and unnecessarily complex. I'd prefer something like this:

class Foo(SQLObject):
    total = CurrencyCol(fromPython=convertFromMoney, toPython=Money)


Hmm...after some thoughts, I don't really want to duplicate this 
declaration for every column of the currency type, but say it just once.
After all, my current version does exactly that, if a bit verbose. ;-)

Still, I'm eager to see a more succint notation for this particular use 
case. May be like this:

MyCurrencyCol = Col.newClass(base=CurrencyCol, fromPython=lambda v: 
v.asString(), toPython=Money)


Btw, have another question with regard to validators. See the class above:

class CurrencyMoneyValidator(validators.Validator):

     def fromPython(self, value, state):
         if isinstance(value, Money):
             return value.getValue()
         return value
     def toPython(self, value, state):
         if isinstance(value, float):
             return Money(value=value)
         return value

Here I have to check if passed in value is not None. Woudn't it be 
better if fromPython/toPython to be called if the value is *not* None - 
to get rid of these if statements.

[SQLObject] Re: Re: datetime column conversions

[Jorge L. G. F. <go...@ie...>]

Oleg Broytmann, Quinta 06 Janeiro 2005 08:15, wrote:

> On Wed, Jan 05, 2005 at 11:12:54PM -0200, Jorge Luiz Godoy Filho wrote:
>> One thing that I was thinking about was making it optional.  Something
>> like adding a parameter "auto_cast=False" (default) or "auto_cast=True"
>> when
>> instantiating the class.  If it is true, then what is read from the
>> database is passed through a conversion to the type it was supposed to
>> be.
>> 
>> Another option was to add a "cast_method=Method" where the default is
>> "None".  If it is a method then everything read from the database is
>> passed to it (where one can make the cast to the desired type with some
>> 'isinstance' checks of the object).  It might be used for other things --
>> filters come to my mind -- too.
> 
>    Easy:
> 
> class Converting(SQLObject):
>     age = IntCol(validator=validators.Wrapper(fromPython=int),
>     default=100)

I have to check the docs on this, but from "intuition", shouldn't it be
"toPython", since the data is coming from the Database?

The process of *sending* to the database should be checked, but how about
what is read from there?  This, IIUC, was the point.

-- 
Godoy.     <go...@ie...>

Re: [SQLObject] On Postel's Law, or: why should SQLObject automatically coerce values on database read

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

On Thu, Jan 06, 2005 at 07:57:34AM -0200, Carlos Ribeiro wrote:
> SQLObject should perform automatic coercion on all the data it fetches
> from the database.

   There is a big misunderstanding between you and me. I have no
objection for conversion from DB to Python. All my objections were about
Python-to-DB conversion.
   If a column .age is the IntCol, I don't want to see the code
atable.age = '1'
   The code must raise TypeError or InvalidField exception. Those who
want such code in their programs will implemet the conversion
themselves and take all responsibility for it.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] datetime column conversions

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

On Thu, Jan 06, 2005 at 11:47:45AM +0200, Max Ischenko wrote:
> register a coersion method, as Carlos suggests.

class Converting(SQLObject):
    age = IntCol(validator=validators.Wrapper(fromPython=int), default=100)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Re: datetime column conversions

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

On Wed, Jan 05, 2005 at 11:12:54PM -0200, Jorge Luiz Godoy Filho wrote:
> One thing that I was thinking about was making it optional.  Something like
> adding a parameter "auto_cast=False" (default) or "auto_cast=True" when
> instantiating the class.  If it is true, then what is read from the
> database is passed through a conversion to the type it was supposed to be.
> 
> Another option was to add a "cast_method=Method" where the default is
> "None".  If it is a method then everything read from the database is passed
> to it (where one can make the cast to the desired type with some
> 'isinstance' checks of the object).  It might be used for other things --
> filters come to my mind -- too. 

   Easy:

class Converting(SQLObject):
    age = IntCol(validator=validators.Wrapper(fromPython=int), default=100)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] On Postel's Law, or: why should SQLObject automatically coerce values on database read

[Carlos R. <car...@gm...>]

Hi all,

I've been insisting on this point (Postel's Law as applied to
software) but I feel that my argument hasn't been convincing. To be
sincere, it's my fault: I haven't presented the argument in a
convincing way. Let's try to correct it.

Postel's Law is one of foundations of Internet design. Why does it
work? Simple: it creates an asymmetry on the strictness requirements.
As a programmer, you must make sure that you play nice. It's something
that *you can control*. But you can't control what other pieces of
software do, so you have to be more open minded about what do they
send to you. Other people may have done it in a slightly different
(but incompatible) way, based on a perfectly reasonable interpretation
of the same standard. Postel's Law is just the realization of an
inherent asymmetry in the problem space.

I believe that Postel's Law principles should apply to any complicate
enough piece of software (and that includes anything bigger than a few
dozen lines). The reason is: the programmer only does have control
over the interface provided by software he's writing, but no control
over the interfaces it uses.

One of the consequences of failing to meet Postel's Law guidelines in
software is the usual fingerpointing exercise. If two pieces of
software do not match, it's usual to hear heated arguments about who
did wrong, and who should correct it. But what if both sides have
reasonable arguments? Simple: the client side must adapt to it, as
reasonably as possible. It's simpler done this way, and consistent.
Better, it avoids surprises.

In SQLObject's case, I believe that the principle is simple. If the
programmer declared an IntCol, it's reasonable to enforce it. But
there's no way one can enforce the same kind of strictness about the
DB driver. I'm not saying this in the strict sense of the int()
conversion, I'm talking about the generic case. That's why I believe
SQLObject should perform automatic coercion on all the data it fetches
from the database.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] datetime column conversions

[Max I. <ma...@uc...>]

Oleg Broytmann wrote:

>>2. Allow the user to set which DateTime he prefers to use, by
>>registering a coercion method. I don't think that this is the same as
>>the validator, though... I assume that this could be done on the class
>>itself, as in:
>>
>>DateTimeCol.DateTime = mx.DateTime.DateTime
> 
> 
>    This is the solution that I'm thinking about. But I think the better
> approach is to create two different subclasses of DateTimeCol (and
> SODateTimeCol) - one for datetime and another for mx.DateTime.

IMO, the approach to build a *whole class* just to provide a user with a 
custom type convertor is flawed. This feature should be directly 
supported by SQLObject. For example, by providing some protocol to 
register a coersion method, as Carlos suggests.

Re: [SQLObject] datetime column conversions

[Max I. <ma...@uc...>]

Barry Warsaw wrote:

> This doesn't feel right because I have to do this transformation for
> every DateTimeCol attribute.  I've only taken a cursory look at the
> code, but maybe it would be better to set a converter on the DateTimeCol
> class, or to subclass, but I haven't gotten either of those approaches
> to work.  Ideally, DateTimeCol would just hand me datetime instances. ;)

In principle, SQLObject provides two means to help you with this - 
validators and converters. Check list archive for UnicodeCol validator 
for instance. Another option would be to subclass a DateTimeCol.

IMO, SQLObject should provide some simpler, more user-friendly way to 
tune it's type-conversion process but AFAIK there is none (yet).

btw, make sure you're using bleeding edge version from 
svn://colorstudy.com/trunk/SQLObject and not out-of-dated 0.6.1 release.

Re: [SQLObject] Re: datetime column conversions

[Carlos R. <car...@gm...>]

On Wed, 05 Jan 2005 23:12:54 -0200, Jorge Luiz Godoy Filho
<go...@ie...> wrote:
> Another option was to add a "cast_method=Method" where the default is
> "None".  If it is a method then everything read from the database is passed
> to it (where one can make the cast to the desired type with some
> 'isinstance' checks of the object).  It might be used for other things --
> filters come to my mind -- too.

There is some overlap between the casting/coercion on read & the the
validator, but I still feel that they are different. *If* for some
reason automatic coercion is added to SQLObject, it should be:

- only for the data received from the database;
- configurable by providing a coercion function or some suitable class
constructor.

As for the suggestion to make it None... it's faster to use a lambda
for this purpose. Something like this could be done:

# standard implementation
doNothing = lambda x: return x
IntCol.coerceVal = doNothing
DateTimeCol.coerceVal = doNothing

# user customization
IntCol.coerceVal = int
DateTimeCol.coerceVal = datetime.datetime


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] datetime column conversions

[Carlos R. <car...@gm...>]

On Wed, 05 Jan 2005 23:21:09 -0600, Ian Bicking <ia...@co...> wrote:
> Oleg Broytmann wrote:
> >>2. Allow the user to set which DateTime he prefers to use, by
> >>registering a coercion method. I don't think that this is the same as
> >>the validator, though... I assume that this could be done on the class
> >>itself, as in:
> >>
> >>DateTimeCol.DateTime = mx.DateTime.DateTime
> >
> >
> >    This is the solution that I'm thinking about. But I think the better
> > approach is to create two different subclasses of DateTimeCol (and
> > SODateTimeCol) - one for datetime and another for mx.DateTime.
> 
> I don't think there should be two classes.  A DateTimeCol isn't actually
> different than an MxDateTimeCol -- they both hold dates, they both look
> the same in the database.  mx.DateTime and datetime should be selected
> with a keyword argument.  Or, maybe it could be configured globally,
> since it's unlikely you'd want to use mx.DateTime in one place and
> datetime somewhere else; but I don't like assigning to a class variable
> like that.  Maybe a class method,
> DateTimeCol.setDefaultImplementation().  In fact, it's just as good if
> it takes a string to indicate which implementation, since their
> interfaces are sufficiently different that you can't deal with the
> module in any abstract way.

Although the interface is different, I believe that the signature of
the constructor (which is what gets used for this kind of coercion) is
the same.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Preparing for 0.6.1

[Stuart B. <st...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Bicking wrote:
| Is there anything people know of that should be resolved before 0.6.1?
| As far as I can remember, it's just been a bunch of bug fixes since 0.6
| (most from Oleg, thanks!)

I would like to see the death of __del__ methods, or at the very least
swallowing any exceptions raised inside them. The spurious warnings are
causing our test suite grief (but it won't be the end of the world if it
isn't in the next release).

__del__ methods seem to have little use except to confuse the Python
garbage collector and generate random bugs, so I personally consider
code that relies on them broken ;)

I'll work on a patch unless someone beats me to it.

- --
Stuart Bishop <st...@st...>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB3PmGAfqZj7rGN0oRAgvQAJ4toPE3kESwokPQ2de7f81pAp+axQCbBGvu
P+R03geRUqWSQ/u6Js/UF5g=
=Xdcm
-----END PGP SIGNATURE-----