Le 23/10/2012 10:17, Sylvain Thénault a écrit :
Hi all,
I've been working on logilab-common py3k compatibility, by attempting to make
tests go to green. For more details, see http://www.logilab.org/ticket/104047.
Mosts tests will be fixed by http://www.logilab.org/patch/109341, but I've
isolated
changes related to the @monkeypatch decorator since they are arguable.
Discussion started
with Aurélien but I think it's worth bringing the subject here.
IMO we've two choices here. First, we could apply the following patch to make
tests
pass: http://www.logilab.org/patch/109340
Or we could restrict the contract of the monkeypatch decorator. The offending
test is the
following:
class XXX(object):
def __call__(self, other):
tester.assertIsInstance(other, MyClass)
return 12
monkeypatch(MyClass)(XXX())
self.assertEqual(MyClass().foo(), 12)
It works in python2 because we added:
if callable(func):
if sys.version_info< (3, 0):
setattr(klass, name, method_type(func, None, klass))
i.e. turning whatever callable into a method. IMO this was not in the primary
idea of monkeypatch
which was expected to be a syntactic sugar easing readability, but doing no
intrusive change
on the "thing" being added to the patched class. In other word,
monkeypatch(Toto)(tutu) should
be equivalent to Toto.tutu = tutu. Also, reading the test I feel this behaviour
weird. If I attempt
to monkeypatch an instance to a class, I don't expect this kind of implicit
closure.
Aurélien, you added this case, was it theorical only or are you aware of any
usage of it?
Though I did not write the original monkeypatch decorator (Adrien
did), I had quite a clear opinion on what purpose it would serve.
Indeed (and imho), most monkeypatches are about replacing/adding a
callable into a class, not just sugar for Foo.bar = bar (you're
describing the whole decorator protocol here).
Monkeypatching-in properties was one of the things I didn't expect,
hence I provided further tests (the ones that annoy you) and an
allowance for non-callables (like properties). In retrospect that
should have been much stricter (allowing only `isinstance(func,
property)`).
(Hence, the `methodtype` thing is only an implementation detail.)
So we had and still have diverging opinions on the purpose of this
decorator.
As we've too choose between breaking compat or adding weird boiler plate to keep
py3k forward compat, I would like other's opinion on this. My personal choice
goes to the second solution.
Why are we facing such a choice in the first place ?
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
