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

2010-12-01 Thread Terry Reedy
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

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

2010-12-01 Thread Nick Coghlan
On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedy tjre...@udel.edu wrote: 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).

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

2010-12-01 Thread 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,

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

2010-12-01 Thread Terry Reedy
On 12/1/2010 8:22 PM, Michael Foord wrote: 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. I was wondering how people

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

2010-12-01 Thread Terry Reedy
On 12/1/2010 8:22 PM, Nick Coghlan wrote: On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedytjre...@udel.edu wrote: 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