On 12/1/2010 8:22 PM, Nick Coghlan wrote:
On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedy 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
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 remem
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, the
On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedy 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).
Given that f
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
redund
