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? I will reask my question: are you aware of any usage of this? > 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. > (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. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org _______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
