[SciPy-Dev] Mea culpa: deprecation and API changes

[Warren Weckesser]

Warren Weckesser wrote:
> Opinion wanted:  codata.find(sub) used to print a list of strings.  A 
> while ago, in response to http://projects.scipy.org/scipy/ticket/996,  I 
> changed it to return the list of strings.  But this is an API change, 
> and should follow the deprecation policy.  One way to do this is to 
> restore find() to its previous behavior, and deprecate the function.  At 
> the same time, add a new function, find_string(sub), which returns the 
> list of strings.  What do you think?
>
>   

Instead of creating a new function, I added a keyword argument whose 
default value (True) preserves the old behavior.  When it is False, it 
returns the keys instead of printing them.  In 0.9, the default behavior 
will be reversed.

Warren

> Warren
>
>
> Warren Weckesser wrote:
>   
>> David Cournapeau wrote:
>>   
>>     
>>> On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
>>> <warren.weckesser at enthought.com> wrote:
>>>   
>>>     
>>>       
>>>> David Cournapeau wrote:
>>>>     
>>>>       
>>>>         
>>>>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>>>>> <warren.weckesser at enthought.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>>>> What I would like to do is leave trunk as it is, and after 0.8 is
>>>>>> branched, make the appropriate changes in the branch to follow the
>>>>>> deprecation policy.  Is that a reasonable approach?
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>> May I ask why do you want to do that way ?
>>>>>       
>>>>>         
>>>>>           
>>>> Because it doesn't look like I will have time to make the changes before
>>>> Ralf branches 0.8 tomorrow.
>>>>
>>>>     
>>>>       
>>>>         
>>>>>  Putting the deprecation in
>>>>> the release branch means people tracking trunk will never see them.
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>>> Good point.    But in case I am misinterpreting what you mean by
>>>> "tracking trunk" and "see":  I assume this means it is important to have
>>>> a record of the deprecation changes in the svn logs, and not that some
>>>> who is *using* scipy from trunk also needs to be exposed to the
>>>> deprecation warning for some minimum amount of time.
>>>>     
>>>>       
>>>>         
>>> actually, I meant both. For example, I often use scipy from trunk, and
>>> rarely from releases.  I will never see the deprecation, which is not
>>> good.
>>>
>>> Also, I think we should generally try to never put things in release
>>> branches, but always backport from trunk (except for branch specific
>>> changes). Having the 0.8 branch created tomorrow does not mean you
>>> cannot put the changes into trunk, and backport them in 0.8 later -
>>> deprecation which were already agreed on are the kind of things which
>>> can happen after the branching without putting much burden on the
>>> release process.
>>>
>>>   
>>>     
>>>       
>>>>  If the changes are
>>>> made to trunk, then they will be undone immediately after 0.8 is
>>>> branched.
>>>>     
>>>>       
>>>>         
>>> deprecated features do not be to be removed just after the trunk is
>>> opened for the next release cycle (0.9 here).
>>>
>>>   
>>>     
>>>       
>>>> ever have a copy that includes the deprecation warnings.  In other
>>>> words, deprecations are linked to releases, not to "time in trunk".
>>>>     
>>>>       
>>>>         
>>> Indeed - but I think that we should let the deprecation be in place
>>> for as long as possible in the source code repository.
>>>
>>>   
>>>     
>>>       
>> OK.  It might be a couple more days before I can make the reversions and 
>> deprecations, but I'll get them in before the beta release on June 6.
>>
>> Warren
>>
>>
>> _______________________________________________
>> 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
>