[Python-Dev] Adding decimal (aka FixedPoint) numbers to Python

Michael McLay mmclay@comcast.net
Sun, 15 Dec 2002 11:02:30 -0500


On Sunday 15 December 2002 04:00 am, Brett Cannon wrote:
> [Michael McLay]
>
> > sf/653938I is a patch to integrate the fixedpoint module, that was
> > created by Tim Peters, into Python as a first class object. That is, the
> > patch adds this new number type so that it has direct syntax support like
> > float, int, long, str., etc. within the interpreter.
>
> Someone will correct me if I am wrong, but making a new decimal type that
> includes a new suffix for numbers is  going to require a PEP.  Your
> email, though, already seems like a rather good start for one and should
> not require much more work.

Yes, there should be a PEP. I posted this as a work in progress because I had 
a question on the semantics and also to get a general sense of what questions 
a PEP might need to answer.
>
> It would be easier to get the module itself sans any Python core changes
> accepted initially to gauge usage and interest by the Python community
> before pushing for syntax integration.  This is what is be done with the
> current rational implementation.

The module has existed for quite some time and is available on sourceforge at 
<http://fixedpoint.sourceforge.net/>. I made some changes to the module and I 
am interested in opinions on the change in the name of the class. 

> I personally would like to see the module included but currently say no to
> any integration into the core syntax.

The syntax change is primarily to make Python more appealing to professions 
that require the semantics of fixed point decimal numbers. Ideally Python 
would only have decimal numbers. The use of binary floating point is a 
performance enhancement and since the language historically has used binary 
numbers for float the switch to using decimal numbers would break backward 
compatibllity. In order to add decimal numbers as an alternative the syntax 
must distinguish floats from decimal. The format I proposed is already used 
to distinguish number types is used for complex and long numbers.  

The syntax change would allow decimal numbers to be used without the clutter 
of a constructor and a quoted string. For example:

msql.execute ("INSERT INTO bankAccount
   VALUES ('%s','%s','%s','%s', (,'Pay Rent'
   ,1256,FixedPoint("1345.23") ,'1999-03-30',NULL)")

would be written as follows:

msql.execute ("INSERT INTO bankAccount
   VALUES ('%s','%s','%s','%s', (,'Pay Rent'
   ,1256,1345.23d ,'1999-03-30',NULL)")

In this case the percentage of clutter is pretty minimal, but if you want to 
use Python as a serious tool for interactive calculations the clutter becomes 
annoynig. For instance:

>>> def CalcAverage(list):
...     total = 0d
...     for i in list:
...        total += i
...     return total/len(list)
...
>>> 
CalcAverage([FixedPoint("123.40"),FixedPoint("222.20"),FixedPoint("300.33"),FixedPoint("400.32")])
FixedPoint("261.56")

Compare that to what would be required if the syntax were built into the 
language:

>>> CalcAverage([123.40d, 222.20d, 300.33d, 400.32d])
261.56d
>>>