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

Thu Aug 20 13:32:08 EDT 2009

Here is what I know about the chararray usage at STScI since first  
looking into it this morning.

It is used in PyFITS and within the COS instrument calibration code.   
I have not heard back from the other projects yet given most of our  
developers are away at this time.

It appears that the COS code can be changed easily.  I am waiting to  
hear back from PyFITs.

Also, I do not know how many people use this particular feature.   
However I would point out that many people who use numpy are not also  
on the mailing lists.  Most of the STScI do not follow the numpy  
list.  I serve as our point of contact to the numpy community.  I'm  
trying to gather a list of projects that use this feature and specific  
use cases for you.  As I do not use this module myself I cannot  
counter your arguments at this time.   If we decide to deprecate this  
module would we reverse this decision if we then find out that the  
assumptions that went into the decision were in error?

Another concern is that we told people coming from numarray to use  
this module.  It is my opinion that at this point in the numpy release  
cycle that an API change needs a very strong justification.  Anecdotes  
about the number of users, a "change or die" philosophy, and an un- 
articulated notion of  "the spirit of numpy"  do not in my  
consideration meet that high bar.  If you would like us to provide  
additional documentation and tests that would be possible.  I'll do it  
myself if that is the only think keeping the module from remaining in  
numpy.

This also raises the question of what else is going to go?  Will  
recarray be removed?  What about the numarray c-api compatibility layer?

Like I said earlier, I'm not opposed to change.  I am just of the  
opinion that this isn't a simple, cut and dry decision.

For those at SciPy 2009 feel free to come yell at me and beat me with  
sticks.  I'm the fat guy in jeans and a blue shirt sitting towards the  
back middle on the left.

Cheers,
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 12:27 PM, David Goldsmith wrote:

> --- 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
>>
>
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion