On 4/28/11 5:10 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 12:25 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
I posted a patch implementing this proposal on the tracker:
Interesting indeed! I'd like to hear from the numpy folks about this.
I'm personally -1, though mostly on general conservative principles. I'm sure there is some piece of code that will break, but I don't know how significant it would be. I'm not sure that it solves a significant problem. I've never actually heard of anyone running into an infinite cycle due to NaNs, though a bit of Googling does suggest that it happens sometimes. I don't think it really moves us closer to IEEE-754 compliance. The standard states (section 7. "Exceptions") "The default response to an exception shall be to proceed without a trap." Python only intermittently turns INVALID operations into exceptions, mostly just (-1.0)**0.5 and integer conversion (0/0.0 and x%0.0 could be considered covered under the division by zero signal that *is* consistently turned into a Python exception). inf-inf, inf/inf, 0*inf, and inf%2.0, to give other examples of INVALID-signaling operations from the spec, all return a NaN without an exception. Given that we want to avoid exposing SIGFPE handlers for safety reasons, I think the status quo is a reasonable compromise interpretation of the spec. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco