[Pypgsql-users] Re: Pypgsql-users digest, Vol 1 #53 - 6 msgs

[terry <tg...@ci...>]

I posted the 'other end' of this problem last week on the Python 
list under "Numeric Data Types".  The result was that there is no 
intrinsic Python Numeric data type, so simple computations such 
as:  Total = Qty * UnitPrice  cannot be done with data from 
Postgres.  Following some of the links showed that there seems to 
be little interest in making an intrinsic numeric data type.  

Until that is done, all database use of numeric data (money) is 
forced into whatever set of constructs one can cobble together 
for the specific instance.  Beware if your software has to go 
through Quality Assurrance, because each calculation using mixed 
variable types will be suspect and will need to be tested 
uniquely.  It sort of says that Python is not suitable for 
accounting applications until they develope an intrinsic numeric 
type that the various database number types can be converted to.


>>  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, but the first one still exists.
>>
>>  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
>>  	PgNumeric('123.45') > 100
>>
>>  raise exceptions instead of returning "false" or "true" (0 or
>> 1).  Of course, one can write:
>>
>>  	type(PgNumeric('123.45')) == type(None)
>>
>>  but it is not so elegant and differs from what we can write
>> for standard built-in Python types:
>>
>>  	123.45 == None
>>
>>  Especially comparing values to None is very popular in
>> database applications as None represents NULL value, am I not
>> right? :)
>>
>>  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__),
>>
>>  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.
>>
>>  Regards,

-- 

terry