Make errstate a decorator #270

Closed
wants to merge 1 commit into
from

5 participants

@jpaalasm

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.

Example:

import numpy

@numpy.errstate(invalid="warn")
def test_func1(a):
    numpy.sqrt(-1)

@numpy.errstate(invalid="raise")
def test_func2():
    numpy.sqrt(-1)

def main():
    test_func1(1)
    test_func2()

main()

Example output:

test_new_errstate.py:100: RuntimeWarning: invalid value encountered in sqrt
  numpy.sqrt(-1)
Traceback (most recent call last):
  File "test_new_errstate.py", line 110, in <module>
    main()
  File "test_new_errstate.py", line 108, in main
    test_func2()
  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
    numpy.sqrt(-1)
FloatingPointError: invalid value encountered in sqrt
@charris
NumPy member

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.

@jpaalasm

What about making the decorator without functools?

@charris
NumPy member

Doing it without functools would be fine.

@njsmith
NumPy member

Also, needs tests.

@charris
NumPy member

ping the travisbot

@charris charris closed this Mar 2, 2013
@charris charris reopened this Mar 2, 2013
@jpaalasm

Now that the next release will drop Python 2.4 support, would it be possible to include this now (with a test, of course)?

@seberg
NumPy member

Sounds good to me, also needs a rebase to merge.

@charris
NumPy member

@jpaalasm Could you rebase this?

@charris
NumPy member

Also needs documentation and a test.

@seberg
NumPy member

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?

@seberg
NumPy member

Oooops, nvm. it already uses the with statement :), completly missed that.

@njsmith
NumPy member

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

@np.errstate(...)
def f(...):
    ...

have over

def f(...):
    with np.errstate(...):
        ...

? 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").

@charris
NumPy member

@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.

@rkern
NumPy member

@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.

@njsmith
NumPy member

Sounds like we have consensus then, so I'll close this.

@jpaalasm: Indeed, thanks for the contribution!

@njsmith njsmith closed this Jul 11, 2013
@mhvk mhvk referenced this pull request in astropy/astropy Oct 16, 2013
Open

Turn numpy warnings into exceptions #1588

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment