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. -- http://mail.python.org/mailman/listinfo/python-list
