On Tue, Oct 1, 2013 at 9:37 PM, <[email protected]> wrote: > Since numpy and scipy just moved to python 2.6, it's time to advertise > and support > warnings.catch_warnings().
warnings.catch_warnings is a very useful tool and this is all fun to talk about, but realistically we're simply not going to merge any change which involves telling people "the way you detect failure in this function is to use the catch_warnings() context manager". > If you want to wait for a "missing value support" in numpy to support > this, then this postpones this to .... (numpy 3.0?) > while gufuncs seem to be happening now. No-one said anything about missing value support :-). I don't see how it would really solve the problem -- we'll probably never allow missing values to magically appear in arbitrary function outputs (e.g. you can't put a bitpattern NA in a regular integer dtype, it's just not possible). On Tue, Oct 1, 2013 at 9:37 PM, Charles R Harris <[email protected]> wrote: > I'm surely not opposed to raising an exception if there is agreement on > that. I think it would also be pretty easy to attach the result to the > exception. For the latter it would be good to have an exception type that we > could maybe reuse for other parts of Numpy. It is true that no-one's ever objected to the ValueError that nanarg{max,min} have raised in the past, right? That seems like one measure of agreement that it's at least acceptable. Spitball of a proper solution, though some thought would need to go into how to get this out of gufuncs. (And absolutely unsuitable for 1.8!): class VectorizedError(object): pass def vectorized_raise(result, good_mask, exceptions): exc_types = set([type(e) for e in exceptions]) exc_types.add(VectorizedError) exc_type = type.__new__(type, "SubVectorizedError", tuple(exc_types), {}) exc = exc_type(" _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
