[DB-SIG] pyformat Parameter Style

jlburly jlburly at yahoo.com
Fri May 16 11:42:28 EDT 2003


--- Magnus Lyckå <magnus at thinkware.se> wrote:
[snip]
> >I STILL believe the better way to handle something
> like floats is to 
> >create a fixed_point type.
> 
> I also want a fixed point type in Python. We agree
> again! :)
> 
> >Nothing stopping us writing our own types/classes.
> Many interfaces do this 
> >already for date/time types.
> 
> But it's difficult to write database interfaces to
> support new
> types or classes written by the application
> programmer...
> 
> I think it's a good thing that a new datetime type
> is added to
> 2.3, and I hope a good fixed point type will be in
> 2.4. Until
> then, this will be a bit shaky.

Until that time, it seems like Tim Peter's FixedPoint
class (http://fixedpoint.sourceforge.net) would be a
good candidate for incorporation in the interim.  How
difficult would this be to implement in the various
drivers?  Adding this type would allow those end users
that work with sql decimal or numeric data types to
have stricter enforcement of decimal arithmetric
through the use of FixedPoint than they would
otherwise by using float.  It seems like this would
also solve a lot of the issues associated with the
mismatch of python float and sql decimal/numeric data
types talked about recently on the list.

Like mentioned above, the handling of FixedPoint could
be similar to how the db api currently specifies the
preference for using the mxDateTime package for sql
date/time data types.  The db api could encourage(?)
end users that want to read/write data from/to exact
numeric data types, such as sql decimal or numeric, to
use FixedPoint, and for those that want to read/write
data from/to approximate numeric data types, such as
sql real, double precision, or float, to use python
float.	

Jeff Lewis


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



More information about the DB-SIG mailing list