Terry J. Reedy added the comment:
Current status: Tim is currently not actively involved in Python development
and no one who is active is enthusiastic about the proposal.
Your proposal is to add dependency injection to the initializer for the 4 diff
classes by adding 6 new parameters. I will comment on the proposal itself
below. But first...
Your initial message in support of the proposal was about as weak as possible:
"it would be possible to ...". Lots of things are possible. For instance, we
could add a Socket class replacement parameter to all stdlib functions and
classes that use socket.Socket (and this has been requested in at least one
case). However, only a few changes actually get done. Recognizing this ...
Your later message gave one use case: Bazaar's experiments with an alternate
implementation. To me, this example is still inadequate justification for a
change. We agree that cut-and-paste is bad (though not terrible for one-off
experiments). That is why Python allows dynamic patching ('monkeypatching') of
modules and Python-coded classes as an alternative (though subclassing is often
better for classes).
import difflib
# either
class MyDiff: pass # not really ;-)
# MyDiff might or might not subclass SequenceMatcher
difflib.SequenceMatcher = MyDiff
# or
def f(self, *args): pass # again, not really
difflib.SequenceMatcher.somemethod = f
# either way, use difflib functions with alternate matcher.
I consider subclassing + dynamic patching an adequate solution* for the one use
case you mention and likely other uses. So I am inclined to reject the
proposal as 'unnecessary'. (If multiple people were routinely monkeypatching
difflib like this, I might change my mind.)
* A context manager can be used to make the monkeypatching temporary and
therefore local in effect. The following works.
@contextlib.contextmanager
def mp(ob, attr, new):
old = getattr(ob, attr)
setattr(ob, attr, new)
yield
setattr(ob, attr, old)
As for the proposal itself: you mention possible API alternatives. I am more
concerned about expanding our responsibility and corresponding test
requirements. If you monkeypatch the module, then you are responsible for the
results. If we add what amount to monkeypatching parameters, then we become
responsible. We would have to make sure that the requirements for replacements
are adequately defined and design at least one non-trivial replacement and run
all the appropriate tests with that replacement. Your patch does not do this.
I would not want to do this. We would also have to be prepared to maintain the
expanded definition of the classes.
Extending the mandate of the four classes from "work reasonably well with the
builtin diff engine" to "work reasonably well with any 'similar' diff engine
passed in by a user" is not as trivial as implied by the patch.
For a simple function like filter, the requirement for the function parameter
is simple. It must be a predicate with respect to the items yielded by the
iterable arguments. That means returning False or True and never raising when
applied to each item. It is easy to create alternatives such as lambda x:
False, lambda x: True, lambda x: bool(x), and lambda x: x < 0, and test with
appropriate iterables.
I hope this explains a bit why function parameters are routine in Python while
class parameters are much less common.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20752>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
