On Thursday 04 October 2007 13:08:08 David M. Cooke wrote:
> Alan G Isaac <[EMAIL PROTECTED]> writes:
> > To help me understand, might someone offer some examples of
> > NumPy names that really should be changed?
>
> Internal classes, like:
> - masked_unary_operation, etc. in numpy/core/ma.py
FYI,
Alan G Isaac <[EMAIL PROTECTED]> writes:
> To help me understand, might someone offer some examples of
> NumPy names that really should be changed?
Internal classes, like:
- nd_grid, etc. in numpy/lib/index_tricks.py
- masked_unary_operation, etc. in numpy/core/ma.py
Things we probably wouldn't
To help me understand, might someone offer some examples of
NumPy names that really should be changed?
Thank you,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> 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. T
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
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote:
> 2) API changes should only be made in major releases, not minor
> releases (IMHO).
+1
> 3) Greater time should be provided to accommodate the transition. For
> example, there should not be deprecation warnings in the first
> version that t
To follow on to my previous posting on this topic given Robert's
response.
As I said previously, I was never strongly committed to one approach
or the other. But since the v1 release has been made, I think more
care needs to be given to consideration of proposals like this before
actually
