[Numpy-discussion] what to do with chararray

Ralf Gommers ralf.gommers at googlemail.com
Thu Aug 20 12:18:07 EDT 2009


[this discussion moved here from the SciPy list]

On Thu, Aug 20, 2009 at 9:50 AM, Christopher Hanley <chanley at stsci.edu>wrote:

> Hi,
>
> 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.


My assumption about there being few users of chararray is based on the
absence of questions about it being asked on the list, the lack of docs and
the apparent lack of a good use-case. Plus "who uses this?" has been asked
twice on the list, and in both cases you (Chris) were the only one replying.


>  I would also like to
> better understand the reasons for wanting to dump it.  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 and a mean
> thing to do to our customers.


That would be a very poor reason, and I don't think that's the case. The
reason this question about the future of chararray has now been asked twice
is that people are trying to document it, and having trouble. If it stays,
it has to be documented (and the bugs found in the process fixed) which
costs time as well. It just being there will also cause people to understand
/ try to use it. Then if it turns out it is useless to those people, it
wasted their time. This was the case for me.

It would be great if we could a clear use-case and a reason why chararray is
in NumPy besides backwards compatibility. Otherwise it should at least be
documented as not for new development, and possibly deprecated.

Finally, deprecation does not mean that the module disappears tomorrow. It
can stick around for years if needed (there are functions in fft for example
that have been deprecated for three years), but give a clear message to new
users not to bother with it.

Best regards,
Ralf



>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090820/93fd2980/attachment.html>


More information about the NumPy-Discussion mailing list