Giovanni Bajo <[EMAIL PROTECTED]> 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
