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

[Gerhard <ger...@gm...>]

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

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))