[Numpy-discussion] Deprecate chararray [was [SciPy-dev] Plea for help]
Thu Aug 20 11:27:45 CDT 2009
--- On Thu, 8/20/09, Christopher Hanley <email@example.com> 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.
> 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.
> Thank you for your time and help,
> 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<firstname.lastname@example.org>
> >> 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
> >> 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 or dictum without major objection. Voting is
> > 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
> > Scipyemail@example.com
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> Scipy-dev mailing list
More information about the NumPy-Discussion