[Python-Dev] fpectl: does a better implementation make sense?

[Michael Hudson]

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