[Python-Dev] Deprecating undocumented, unused functions in difflib.

[Michael Foord]

On 01/12/2010 20:23, Terry Reedy wrote:
> Difflib.SequenceMatcher object currently get two feature attributes:
> self.isbjunk = junk.__contains__
> self.isbpopular = popular.__contains__
>
> Tim Peters agrees that the junk and popular sets should be directly 
> exposed and documented as part of the api, thereby making the 
> functions redundant. The two functions are not currently documented 
> (and should not be now). A google codesearch of 'isbjunk' and 
> 'isbpopular' only returns hits in difflib.py itself (and its 
> predecessor, ndiff.py).
>
> It would be easiest to just remove the two lines above.
> Or should I define functions _xxx names that issue a deprecation 
> warning and attach them as attributes to each object? (Defining 
> instance methods would not be the same).
>
> There is only one internal use of one of the two functions which is 
> easily edited.
>
I would still be tempted to go through a single release of deprecation. 
You can add a test that the names are gone if the version of Python is 
3.3. When the tests start failing the code and the tests can be ripped out.

All the best,

Michael

-- 

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.