[SciPy-dev] adopting Python Style Guide for classes

[Perry Greenfield]

On Oct 3, 2007, at 3:16 PM, Robert Kern wrote:

>
> The warnings module allows one to filter warnings very  
> specifically, down to the
> line number in the module where the warning is issued. If you can  
> catalog the
> warnings that are raised by your application (say by running your  
> test suite),
> then you can filter out just those.
>
Yeah, I know, but the thing that wasn't obvious is which module is  
listed when the error is raised. If the warning is raised in numpy,  
isn't that the module it is associated with? After all, how does it  
know where in the call stack you really are interested in associating  
that error with? Or does the warnings module see if that module you  
have listed is in the call tree rather than the warning originating  
in that module? From the PEP and online docs, it seems that module is  
associated with the place the warning is raised. That would work ok,  
but it means you turn it off for everything, not just your code, right?

Another point is, that there has to be time for the code with the  
error suppression specific stuff to be released. It's risky to put  
that in our stuff and release it and find that some changes in numpy  
make it incorrect if numpy is released after it is. Just this aspect  
drives release dependencies more than I would like. There isn't a  
simple solution to this, but if the first version has optional  
warnings, it makes it easier to test against it for the applications  
release.

>>>> 5) In my humble opinion, we would be nuts--absolutely nuts--to  
>>>> change
>>>> either the type classes or the factory functions. This would be
>>>> foolish consistency at it's worst. We *just* went through the
>>>> exercise of changing Int32 to int32 and so forth and we would  
>>>> have to
>>>> change back again? This cannot be seriously considered.
>>> I think that the general consensus is that we should keep int32,
>>> rather than switch to Int32.
>>
>> That's good. But what about array(), zeros(), ones(), arange(), etc.?
>
> They're all functions and not affected.

Good. I know they were functions, but I think some were arguing that  
even though they were functions, that they should adopt class-name  
conventions because they were object factories so it is good to be  
explicit about this as well.

Perry