--- On Thu, 8/20/09, Christopher Hanley <chan...@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_goldsm...@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-...@scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > _______________________________________________ > Scipy-dev mailing list > scipy-...@scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion