[Numpy-discussion] [SciPy-dev] adopting Python Style Guide for classes
Wed Oct 3 14:08:01 CDT 2007
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.?
More information about the Numpy-discussion