What's needs to be done to possibly get PEP754 (fpconst) to move ahead and perhaps go into 2.4? --Ivan
On Fri, Apr 23, 2004, Ivan R. Judson wrote:
What's needs to be done to possibly get PEP754 (fpconst) to move ahead and perhaps go into 2.4?
Nothing, because it ain't gonna happen. In order for PEP754 to work, we need to have a bunch of people volunteer to maintain the IEEE-754 semantics for a bunch of difference platforms. Feel free to try to drum up interest, but the PEP won't be accepted until there's evidence that people are making long-term commitments. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "I used to have a .sig but I found it impossible to please everyone..." --SFJ
Aahz
On Fri, Apr 23, 2004, Ivan R. Judson wrote:
What's needs to be done to possibly get PEP754 (fpconst) to move ahead and perhaps go into 2.4?
Nothing, because it ain't gonna happen. In order for PEP754 to work, we need to have a bunch of people volunteer to maintain the IEEE-754 semantics for a bunch of difference platforms.
The PEP offers a reference implementation in pure Python. (Although the link given is broken). The implementation is just about creating and manipulating specific bit patterns stored in floats. How useful the module is (given that Python doesn't mandate that floats are stored using IEEE-754 format) I couldn't comment. But I'll note that the standard library already contains modules which only work on specific types of platform. As to the inclusion of the module, I have no opinion... Paul. -- This signature intentionally left blank
[Ivan Judson]
What's needs to be done to possibly get PEP754 (fpconst) to move ahead and perhaps go into 2.4?
+ The implementation URL in the PEP no longer resolves, so that needs to be fixed. + Last time I saw it, fpconst.py had a Pfizer copyright and license, which makes headaches for everyone. + It needs docs. + It needs a test suite. + Guido has to Pronounce on it. [Aahz]
In order for PEP754 to work, we need to have a bunch of people volunteer to maintain the IEEE-754 semantics for a bunch of difference platforms. Feel free to try to drum up interest, but the PEP won't be accepted until there's evidence that people are making long-term commitments.
That isn't a good objection for this specific patch -- it's pure Python, and picks apart bits using the struct module. IIRC, it wasn't correctly written for most 64-bit boxes, but that looked like a shallow flaw (I think it assumed that a struct "l" format code, in native mode, always yields a 32-bit thingie).
[Ivan Judson]
What's needs to be done to possibly get PEP754 (fpconst) to move ahead and perhaps go into 2.4?
This one seems to have slipped through the cracks. I haven't heard from the author lately; hopefully he hasn't lost interest. In any case, an active champion is needed for progress. Tim Peters wrote:
+ The implementation URL in the PEP no longer resolves, so that needs to be fixed.
A Google search resulted in: http://www.analytics.washington.edu/statcomp/projects/rzope/fpconst/ I've updated the PEP.
+ Last time I saw it, fpconst.py had a Pfizer copyright and license, which makes headaches for everyone.
+ It needs docs.
+ It needs a test suite.
+ Guido has to Pronounce on it.
Is Guido's waiting for your (Tim's) recommendation? Guido wrote,
"David, I'll leave the review of this PEP entirely to Tim, if you
don't mind". At the time (2003-10-05) Tim wrote:
Guido and I have discussed this in email today. We're both
favorable. It may get buried under feature creep, though (that
is, if the PEP is good so far as it goes, it may be necessary to
make it go farther, addressing some of the other problems
mentioned-- but not solved --by the PEP).
Gregory Warnes (the PEP author) had a few questions the next day
(2003-10-06); I wasn't copied on replies if any. Shall I forward
Gregory's messages to you? I'm copying Gregory on this message.
--
David Goodger http://starship.python.net/~goodger
Python Enhancement Proposal (PEP) Editor http://www.python.org/peps/
(Please cc: all PEP correspondence to
That isn't a good objection for this specific patch -- it's pure Python, and picks apart bits using the struct module. IIRC, it wasn't correctly written for most 64-bit boxes, but that looked like a shallow flaw (I think it assumed that a struct "l" format code, in native mode, always yields a 32-bit thingie).
I was just wondering, now that C99 supports part of IEEE754, should we really get into the job of implementing our own mechanism? As an example, the attached patch exports part of the C99 interface to Python. If we agree that this is something interesting to have in Python, I'll be willing to prepare a patch including support for this interface and hacking some bits to introduce a better IEEE754 support (e.g. checking nan comparisons, etc). -- Gustavo Niemeyer http://niemeyer.net
participants (6)
-
Aahz -
David Goodger -
Gustavo Niemeyer -
Ivan R. Judson -
Paul Moore -
Tim Peters