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
>>>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4