Re: [Pypgsql-users] Comparing PgNumeric etc. with other data types.

[Billy G. A. <bg...@mu...>]

Gerhard =?iso-8859-1?Q?H=E4ring?= wrote:
> * Adam Buraczewski <ad...@po...> [2002-07-29 00:46 +0200]:
> > Hallo,
> > 
> > Recently I found that some PgXXX classes defined in PgSQL module lack
> > some features I would expect because of the fact that they are
> > wrappers around PostgreSQL basic data types.  For example, PgNumeric
> > class is a wrapper around "numeric" type, so it should behave like a
> > Python number: it should be comparable to other numeric Python types
> > and it should be usable as a logical value (false when zero and true
> > when non-zero).  However, PgNumeric values behave differently: they
> > cannot be compared to other, non-PgNumeric, types/classes and they
> > always are "true" in logical expressions despite of their real value.
> > I found the patch on pyPgSQL site which solves the latter problem,
> 
> Committed now with the addition of __pos__ and __abs__ (for the + and
> abs unary "operators").
> 
> > but the first one still exists.
> 
> Indeed. It's not obvious for me how to fix this, as I'm not very
> proficient with emulating numeric types. It _seems_ that you can get a
> lot further by just adding something like this at the start of
> PgNumeric's __coerce__ method:
> 
>     if not isinstance(other, PgNumeric):
>         other = PgNumeric(str(other))
> 
> I have a gut feeling, however, that this isn't all that'll be involved
> for PgNumerics. That's why I haven't commited this, yet.
> 
> > IMHO the most annoying problem is that PgNumeric values cannot be
> > compared to data values of other type, for example following
> > expressions:
> > 
> > 	PgNumeric('123.45') == None
> 
> Ouch! As has been said already, this isn't good practise. But I learnt
> it only relatively recently myself. The reason is that None is a
> singleton and singletons are best compared using "is". This avoids
> potential bugs, and is a lot faster.
> 
> > [...] Especially comparing values to None is very popular in database
> > applications as None represents NULL value, am I not right? :)
> 
> Yeah. That's why you should do it like in SQL and compare using the
> "is"-operator :)
> 
> > Since I am going to write some new programs using pyPgSQL library, I
> > think I could contribute a patch to PgSQL module, which would solve
> > problems described above.  However I would like to know:
> > 
> > 1. if compatibility with Python < 2.1 should be kept (I would like to
> > use new __lt__, __eq__ etc. method names instead of __cmp__),
> 
> I myself haven't used Python 2.0 for years, but it's probably a bad idea
> to break Python 2.0 compatibility in the pyPgSQL 2.x line at this point.
> If you'd like to contribute to the upcoming (not started yet) pyPgSQL 3.0
> instead, you could even use all the cool Python 2.2-only features ;-)
> 
> > 2. if PgNumeric, PgInt8 and other wrappers around PostgreSQL numeric
> > types should be comparable to each other or to standard Python numeric
> > types (float, long, int) only.
> 
> IMO, they should be comparable to all numeric types. I just noticed that
> currently, they aren't.

I noticed that, at least in Python 2.2, that coerce is not being called.  I should have a fix for this shortly.
-- 
____       | Billy G. Allie    | Domain....: Bil...@mu...
|  /|      | 7436 Hartwell     | MSN.......: B_G...@em...
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |