[Python-Dev] fpectl: does a better implementation make sense? (original) (raw)
Giovanni Bajo rasky at develer.com
Fri Dec 1 02:19:17 CET 2006
- Previous message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Next message: [Python-Dev] fpectl: does a better implementation make sense?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
I spent my last couple of hourse reading several past threads about fpectl. If I'm correct
- fpectl is scheduled for deletion in 2.6.
- The biggest problem is that the C standard says that it's undefined to return from a SIGFPE handler. Thus, it's impossible to traps floating point exceptions and convert them to Python exceptions in a way that really works.
- 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 am not arguing that this should be the default behaviour, 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 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.
Is this suggestion still valid or people changed their mind meanwhile? Would such a rewrite of fpectl (or a new module with a different name) be accepted?
Giovanni Bajo
- Previous message: [Python-Dev] Python and the Linux Standard Base (LSB)
- Next message: [Python-Dev] fpectl: does a better implementation make sense?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]