It would be very useful to be able to define floating point error handling per function. For example, you may know that a particular function triggers a harmless underflow (e.g. in computing probabilities), but you would like to keep error handling strict for other functions.
This patch implements a decorator interface to errstate.
test_new_errstate.py:100: RuntimeWarning: invalid value encountered in sqrt
Traceback (most recent call last):
File "test_new_errstate.py", line 110, in <module>
File "test_new_errstate.py", line 108, in main
File "test_new_errstate.py", line 89, in func_with_error_handling
return func(*args, **kwargs)
File "test_new_errstate.py", line 104, in test_func2
FloatingPointError: invalid value encountered in sqrt
Make errstate a decorator
I like the idea, but we can't use functools until we drop support for 2.4. The same holds for the with statement. We will definitely move the supported version up at some point, perhaps after 1.7, but not yet.
What about making the decorator without functools?
Doing it without functools would be fine.
Also, needs tests.
ping the travisbot
Now that the next release will drop Python 2.4 support, would it be possible to include this now (with a test, of course)?
Sounds good to me, also needs a rebase to merge.
@jpaalasm Could you rebase this?
Also needs documentation and a test.
Actually I randomly got wondering about it. Would it be more pure if this thing used a try: ... finally: ... block? Otherwise if the function errors it seems it might fail to reset the error state?
try: ... finally: ...
Oooops, nvm. it already uses the with statement :), completly missed that.
Now that I look, I'm... not at all a fan of this API. IMHO decorators should be used for things that are about "functions", i.e., generally API stuff. Functions shouldn't be treated as just a way to demarcate a chunk of code where you want something to happen -- that's what with and try/finally are for.
What advantage does
? It's not easier to read, it's less python-idiomatic, as a user of f I don't care about the errstate (it's an implementation detail) so having it in between me and the function declaration is confusing, and it's just adding a second way to do things for no purpose AFAICT (violating "there's only one way to do it").
@njsmith I agree, actually ;)
OT, there are a lot of places in the code that could use this context manager now that support for 2.4 and 2.5 has been dropped. I didn't know it existed.
@njsmith While I happen to agree with you in this case, this kind of thing is one of the reasons decorators were introduced to the language, so we shouldn't be too surprised that it gets proposed from time to time, especially when we were supporting 2.5. It just so happens that context managers showed up in the language later and are more (IMHO) fit for purpose. np.errstate() is already a context manager, so I agree that it should not grow decorator functionality as well.
@jpaalasm Thank you for your contribution! I think it made a lot of sense when you proposed it. With our dropping of pre-with-statement Pythons, though, I think that we should keep np.errstate() as it is.
Sounds like we have consensus then, so I'll close this.
@jpaalasm: Indeed, thanks for the contribution!