[SciPy-dev] adopting Python Style Guide for classes
Wed Oct 3 14:51:08 CDT 2007
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
>>>> 5) In my humble opinion, we would be nuts--absolutely nuts--to
>>>> 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.
More information about the Scipy-dev