[Python-Dev] Deprecating undocumented, unused functions in difflib. (original) (raw)
Terry Reedy tjreedy at udel.edu
Thu Dec 2 04:09:14 CET 2010
- Previous message: [Python-Dev] Deprecating undocumented, unused functions in difflib.
- Next message: [Python-Dev] Deprecating undocumented, unused functions in difflib.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/1/2010 8:22 PM, Nick Coghlan wrote:
On Thu, Dec 2, 2010 at 6:23 AM, Terry Reedy<tjreedy at 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). Given that functions are converted to bound methods only on retrieval from an instance, why wouldn't it be the same?
The two SequenceMatcher instance attributes are bound functions of the two sets, not of the instance. But you are right in the sense that the usage would be the same. Since, as of a week ago, the sets were implemented as dicts, any code depending on the class of the underlying instance is already broken. So I will go with S-M methods and add a doc string like "Undocumented, deprecated method that will disappear in 3.3. Do not use!" to show up in a help() listing.
But yes, if you want to get rid of them, then deprecation for 3.2 and removal in 3.3 is the way to go.
OK.
Alternatively, not deprecating them at all and just leaving them undocumented with a comment in the source to say they have been deliberately omitted from the docs would also be fine.
Too messy and too useless ;-).
-- Terry Jan Reedy
- Previous message: [Python-Dev] Deprecating undocumented, unused functions in difflib.
- Next message: [Python-Dev] Deprecating undocumented, unused functions in difflib.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]