[Numpy-discussion] Deprecate chararray [was [SciPy-dev] Plea for help]

[David Goldsmith]

--- On Thu, 8/20/09, Christopher Hanley <chanley at stsci.edu> wrote:

> I'd like to respectfully request that we move any
> discussion of what  
> to do with the numpy.char module to the numpy list.

NP, done.

> I'm a little concerned about some of the assumptions that
> are being  
> made about the number of users of the module.  I would
> also like to  
> better understand the reasons for wanting to dump it. 

I think Ralf did a pretty good job of synopsizing the reasons for deprecation, but since we're moving the thread, I'll reprint them here:

0) "it gets very little use" (an assumption you presumably dispute);

1) "is pretty much undocumented" (less true than a week ago, but still true for several of the attributes, with another handful or so falling into the category of "poorly documented");

2) "probably more buggy than most other parts of NumPy" ("probably" being a euphemism, IMO);

3) "there is not a really good use-case for it" (a conjecture, but one that has yet to be challenged by counter-example); 

4) it's not the first time its presence in NumPy has been questioned ("as Stefan pointed out when asking this same question last year")

5) NumPy already has a (perhaps superior) alternative ("object arrays would do nicely if one needs this functionality");

to which I'll add:

6) it is, on its face, "counter to the spirit" of NumPy.

So far, IIRC, the only reason in favor of its continued inclusion is inertia.

> Let me be  
> clear.  I'm not opposed to change.  However
> breaking other people's  
> code just for the sake of change seems like a poor reason

So, I don't think we're proposing this "just for the sake of change"

> and a mean  
> thing to do to our customers.

Apologies, but it is not proposed maliciously.

The only other things I would add by way of "review" from the scipy-dev thread:

a compromise proposal (made by Ralf):

"Put clearly in the docs that this module exists for backwards compatibility reasons, and is not recommended for new development"

and a clarification of deprecation process (provided by Robert):

"[asked by the present author] How has deprecation in Numpy worked in the past - by dictum, vote, or consensus?

[Robert's answer] Consensus or dictum without major objection. Voting is pointless except to inform one of those." 

Thanks for your time and consideration.

David Goldsmith

> Thank you for your time and help,
> Chris
> 
> 
> -- 
> Christopher Hanley
> Senior Systems Software Engineer
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21218
> (410) 338-4338
> 
> On Aug 20, 2009, at 1:35 AM, Robert Kern wrote:
> 
> > On Wed, Aug 19, 2009 at 20:03, David  
> > Goldsmith<d_l_goldsmith at yahoo.com>
> wrote:
> >> I'm going to take it a step further: "breakage" is
> always the  
> >> deterrent to change, and yet "change we must"
> (i.e., "adapt or  
> >> die").  It's certainly not without precedent
> - even within Numpy, I  
> >> believe - for things (though perhaps not whole
> namespaces) to be  
> >> deemed "to-be-deprecated," have a warning to this
> effect  
> >> established in one x.[even #].0 release, and then
> be removed by the  
> >> x.[even # + 2 or + 4].0 release.  How has
> deprecation in Numpy  
> >> worked in the past - by dictum, vote, or
> consensus?
> >
> > Consensus or dictum without major objection. Voting is
> pointless
> > except to inform one of those.
> >
> > -- 
> > Robert Kern
> >
> > "I have come to believe that the whole world is an
> enigma, a harmless
> > enigma that is made terrible by our own mad attempt to
> interpret it as
> > though it had an underlying truth."
> >  -- Umberto Eco
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>