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
