[Numpy-discussion] Re: seterr changes

[Travis Oliphant]

Tim Hochberg wrote:
>
> Hi Travis et al,
>
> I started looking at your seterr changes. 
Thank you very much for the help on this.  I'm not an expert on threaded 
code by any means.  In fact, as you clearly point out, I don't eat and 
drink what will work under threaded environments and what wont.  Clearly 
global variables are problematic.  That is the problem with the 
update_use_defaults bit, right?   This is the way it was being managed 
before and I just changed names a bit to use PyThreadState_GetDict for 
the dictionary (it seems possible to use only from C until Python 2.4).  

I say if it only buys 5% on small arrays then it's not worth it as there 
are other fish to fry to make up for that 5% and I agree that tracking 
down threading problems due to a fanagled global variable is sticky.  I 
did not think about the threading issues deeply enough.

> I'm also curious about the seterr interface. It returns 
> ufunc_values_obj. I'm wasn't sure how one is supposed to pass that 
> back in to seterr,  so I modified seterr to instead return a 
> dictionary. I also modified it so that the seterr function itself has 
> no defaults (or rather they're all None). Instead, any unspecified 
> values are taken from the current error state. Thus 
> seterr(divide="warn") changes only the divide state, leaving the other 
> entries alone.
Returning an object is a late-in-the-game idea and should be critiqued.  
It can be passed to seterr (an attribute check grabs the actual list --- 
did you want to change it to a dictionary?).  Doesn't a small list have 
faster access than a small dictionary?  

I'll look over your commits and comment later if I think of anything...

I'm thrilled with your work.

Best,

-Travis