[Python-Dev] fpectl: does a better implementation make sense? (original) (raw)

Michael Hudson mwh at python.net
Fri Dec 1 10:21:50 CET 2006

Giovanni Bajo <rasky at develer.com> writes:

Hello,

I spent my last couple of hourse reading several past threads about fpectl. If I'm correct 1) fpectl is scheduled for deletion in 2.6. 2) The biggest problem is that the C standard says that it's undefined to return from a SIGFPE handler.

Well, I'm not sure that's the "biggest" problem in any sense: C also doesn't say anything about how to set things up so that 1.0/0.0 gets you a SIGFPE.

Thus, it's impossible to traps floating point exceptions and convert them to Python exceptions in a way that really works.

"Impossible" is a strong word :-) But yeah.

3) Moreover, the current implementation of PyFPE* macros (turning on/off the traps + setjmp) are pretty slow, so they're off by default.

Now, I would like Python to rause exceptions (FloatingPointError) whenever a Inf or NaN is computed or used in calculations (which to the best of my little understanding of 754 basically means that I want all FPU errors to be detected and handled).

I suggest starting from here and forgetting about fpectl.

I am not arguing that this should be the default behaviour,

Good :-)

I'm just saying that I would like if there was a way to enable this (even if only at Python compile time, in fact).

I think I would too.

I read that Tim Peters suggested several times to rewrite fpectl so that it does not use traps/signals at all, but just checks the FPU bits to see if there was a FPU error. Basically, the PyFPE BEGIN macro would clear the FPU bits, and the STOP macro would check for FPU errors and raise an appropriate exception if needed.

This is part of the reason I want to rip out fpectl: I think a new set of macros is called for, if only so they can have better names. But you'll end up fighting a series of aggravating battles with compiler optimizations and platform support and so on. Did you read this post:

http://mail.python.org/pipermail/python-list/2005-July/331509.html

and the thread it came from?

Is this suggestion still valid or people changed their mind meanwhile?

I haven't changed my mind appreciably.

Would such a rewrite of fpectl (or a new module with a different name) be accepted?

I would at least try to review it and press for its inclusion.

Cheers, mwh

-- The bottom tier is what a certain class of wanker would call "business objects" ... -- Greg Ward, 9 Dec 1999

More information about the Python-Dev mailing list