Grant Edwards wrote: > On 2008-02-10, Jeff Schwab <[EMAIL PROTECTED]> wrote: >> Neal Becker wrote: >>> [EMAIL PROTECTED] 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). -- http://mail.python.org/mailman/listinfo/python-list
