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

[Adam B. <ad...@po...>]

On Mon, Jul 29, 2002 at 03:23:12AM +0200, Gerhard H=E4ring wrote:
> > 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").

Great!  I'll get it in a few minutes :)

> > 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:
>=20
>     if not isinstance(other, PgNumeric):
>         other =3D PgNumeric(str(other))
>=20
> 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.

I'll try to read more about implementing numeric types in Python.  I
feel that the section "3.3.6 Emulating numeric types" of the manual
does not answer all my questions, so I am going to look into some
mathematical Python libraries as well.  I'll write here about my
findings.
>=20
> > [...] 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 :)

OK, now I understand this :)

> > 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 ide=
a
> 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 ;-)

After some thinking I found that probably __cmp__ should be enough for
PgNumeric and other types, so compatibility with Python 2.0 could be
preserved.  Unless my studies on mathematical libraries (above) would
prove something different, but even in this case I can define both
__cmp__ and __lt__ and the latter will be used by Python >=3D 2.1
automatically.

> IMO, they should be comparable to all numeric types. I just noticed tha=
t
> currently, they aren't.

That's clear.

Thanks a lot for the answers!

Regards,

--=20
Adam Buraczewski <ad...@po...> * Linux registered user #165585
GCS/TW d- s-:+>+:- a- C+++(++++) UL++++$ P++ L++++ E++ W+ N++ o? K? w--
O M- V- PS+ !PE Y PGP+ t+ 5 X+ R tv- b+ DI? D G++ e+++>++++ h r+>++ y?