modifying standard library functionality (difflib)

[Bruno Desthuilliers]

Vlastimil Brom a écrit :
> Hi all,
> I'd like to ask about the most reasonable/recommended/... way to
> modify the functionality of the standard library module (if it is
> recommended at all).

(snip)
> However, I'd like to ask, how to best maintain this modified
> functionality in the sourcecode.
> I tried some possibilities, which seem to work, but I'd appreciate
> suggestions on the preferred way in such cases.
> - It is simply possibly to have a modified sourcefile difflib.py in
> the script directory.

You'd better do real fork then and rename the damn thing to avoid 
confusions and name shadowing.


> - Furthermore one can subclass difflib.SequenceMatcher an overide its
> __chain_b function (however the name doesn't look like a "public"
> function ...

It's indeed a very "private" one. Beware of name mangling here, can lead 
to surprising results !-)

Also, overriding an implementation method, your code might break with 
each new release, so it kind of tie you to a specific version (or set 
of...). The odds depend on difflib's source code stability.

> - I guess, it wouldn't be recommended to directly replace
> difflib.SequenceMatcher._SequenceMatcher__chain_b ...

For which definition of "directly replace" ? If you mean patching the 
standardlib's source code inplace, then it's definitly not something i'd 
do.  Monkeypatching OTHO is sometimes the simplest solution, specially 
for temporary fixes or evolutions.

Anyway - which solution (forking, subclassing or monkeypatching) is the 
most appropriate really depends on the context so only you can decide. 
If it's for personal use only and not mission-critical, go for the 
simplest working solution. If it's going to be publicly released, you 
may want to consider contacting the difflib maintainer and submit a 
patch, and rely on a monkeypatch in the meantime. If you think you'll 
have a need for more modifications / specialisations / evolution to 
difflib, then just fork.

My 2 cents.