[Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes

[Sebastian Haase]

On 10/3/07, Perry Greenfield <perry at stsci.edu> wrote:
>
> On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
>
> >
> >> 3) Greater time should be provided to accommodate the transition. For
> >> example, there should not be deprecation warnings in the first
> >> version that this API appears in. The first release of this should
> >> not lead to nuisance messages for those that have other software that
> >> depends on this. (A tool that allows conditional messages would be
> >> good, but the default should be no message). The next release, sure.
> >> As a result, it means that the old API can't be removed until at
> >> least two releases after that.
> >
> > I am not sure I agree with this.  For example, I think it would be
> > acceptable for NumPy 1.1.0 to have deprecation warning about changed
> > APIs.  Perhaps you were saying that NumPy 1.0.4 could use the new
> > class names in addition to the old names without complaint.  That
> > sounds reasonable to me.  Then when NumPy 1.1.0 comes out the old
> > style names would raise deprecation warnings.
> >
> The situation I'm trying to avoid is a too tight coupling between
> numpy changes and client applications that use numpy. Suppose we
> distribute an application that uses numpy. We could make the changes
> to our application before the api-change release comes out (from svn)
> and then when we release our new version (very soon after the api-
> changed numpy comes out) we effectively force all of our users to
> update immediately. The problem is that they may not want to update
> on our schedule. They become annoyed at us.
>
> So we take the other tack, we wait for a while before changing our
> code to require the new numpy. This give the user community time to
> switch their stuff too. But, now our code generates annoying
> deprecation warnings that are useless to the people we distribute
> applications to if they update to the new numpy before we do. Here's
> where I display some ignorance. If the warnings use the standard lib
> warning module, I'm guessing that we can add warnings filters to
> suppress any warnings that arise from our code (but not having much
> experience with it, it isn't clear to me whether the filter
> suppresses all warnings arising from numpy or whether one can
> suppress only those associated with ones that are from the
> applications use). But it's good to clarify this point. If they are
> present by default, an application needs to be able to suppress them.
>
>
> >> 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.?
>
Just to express my worries:  I hope that numpy stays "easily typable"
as a numerical and interactive (!)  environment.
What I'm trying to say:
IMHO,  "arange" should stay lower case, like "range", even if it might
be (internally) implemented as a class.
Similarly, many functions/objects/classes have a functional "feeling"
to them, even tough they be implemented as classes.

My 2 cents.
-Sebastian Haase