Le 23/10/2012 11:14, Sylvain Thénault a écrit :
On 23 octobre 10:45, Aurélien Campéas wrote:
Le 23/10/2012 10:17, Sylvain Thénault a écrit :
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).
You mean in your opinion the case of adding an instance with __call__
as showed is correct and doesn't feel weird?
Yes.
I will reask my question:
are you aware of any usage of this?
No.
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)`).
I don't get your point. I'm not talking about property and monkeypatching
a property works perfectly well, and is out of the scope of this discussion
which is only about the case where one monkeypatch an **instance** with
**__call__** implemented.
I don't have the full history and decision backlog that lead to that
decision unfortunately. Believe me, it was related, then (even maybe if
only as a figment of my imagination).
(Hence, the `methodtype` thing is only an implementation detail.)
So we had and still have diverging opinions on the purpose of this
decorator.
IMO this is not an implementation detail, as it change the contract of what
the function is doing in the case detailed above. Also, I'm not sure to
understand in what our opinions diverge in the whole picture.
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 ?
Because IMO the behaviour vs callable instance in python2 is very arguable,
somewhat unexpected (to me at least), definitly a very dark corner case, and
cause pb with python3 compat.
On thing I can remember: it seemed perfectly reasonnable to define
monkeypatch as operating on callables at the time (with the properties
allowance).
If you accept callables, you should test for __call__ able instances
also, hence the test. I'm not saying people do this or even should do
it, but it is (was at least) acceptable and should work.
Now, to move on, I have nothing against dropping the current type
constraints if one can get reasonnable evidence that if wont break code.
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
