On 26 octobre 13:01, Aurélien Campéas wrote: > 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.
Nothing prevents one to monkey patch a callable to a class. But, not as monkeypatch does currently by turning it into an unbound method. The rational behind my proposal is that @monkeypatch should keep the bare class assignment rules, not add any semantic. ie @monkeypatch of a function will add the function to the class dict, which is turned into an unbound/bound *when accessed through the class/instance*, @monkeypatch of a descriptor, as property, add the descriptor to the class dict, which will allow calls to the descriptor interface *when accessed through the class/instance*, and at last, @monkeypatch whatever else, including a non-function callable, add whaterver else to the class dict without any transformation. Meaning in the callable case that it won't be turned by an unbound method when accessed through the class, as there is no such rule in the python access protocol. > Now, to move on, I have nothing against dropping the current type > constraints if one can get reasonnable evidence that if wont break > code. I don't see proper way to keep bw compat for this corner case if we decide to fix the @monkeypatch semantic. Though, as you, I don't have any client usage in mind, so it seems acceptable to me. -- 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 [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
