Turn off ZeroDivisionError?

[Jeff Schwab]

Grant Edwards wrote:
> On 2008-02-10, Jeff Schwab <jeff at schwabcenter.com> wrote:
>> Neal Becker wrote:
>>> endangeredmassa at gmail.com wrote:
>>>
>>>> Would a wrapper function be out of the question here?
>>>>
>>>> def MyDivision(num, denom):
>>>>     if denom==0:
>>>>         return "NaN"
>>>>     else
>>>>         return num / denom
>>> I bought a processor that has hardware to implement this.  Why do I want
>>> software to waste time on it?
>> Will the amount of time wasted by the software exceed the amount of time 
>> required to implement Python-level access to the hardware feature?
> 
> The "time required to implement Python-level access to the
> hardware features" is simply the time required to delete the
> lines of code that raise an exception when demon is 0.0

You mean the C code that implements the interpreter?  Assuming the 
developer is comfortable getting the Python source code, modifying it, 
compiling and deploying the modified version:  In the best case, the 
change introduces a portability nightmare.  In the worst case, you break 
all kinds of existing code, possibly in the standard libraries, that 
assumes an exception will be throw on any attempt to divide by zero.

>> At any rate, the work-around should at least let you work on
>> the rest of the application, while a more efficient
>> implementation can be developed.
> 
> A more efficient implementation?  Just delete the code that
> raises the exception and the HW will do the right thing.

"Just fork python" is not a simpler solution than "just use this 
pure-python function."  Whether it's worth the headache can be 
considered at length, but in the meantime, the pure-python solution is 
quicker, safer way to continue development of the client code that 
requires the functionality (NaN on divide-by-zero).