Author ncoghlan
Recipients Alexander.Belopolsky, Christophe Simonis, anacrolix, belopolsky, eckhardt, ironfroggy, jackdied, jcea, ncoghlan, r.david.murray, rhettinger, ssadler
Date 2013-06-05.04:48:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I don't believe it is reasonable to change the behaviour of partial at this late stage of the game. It's documented as behaving like staticmethod (albeit by not implementing the descriptor protocol at all), so that's no longer something we can change. If issue 11470 is added, then we'll just implement the staticmethod-like behaviour explicitly rather than leaving it as implicit.

More importantly, the acceptance of PEP 443's functools.singledispatch makes it more desirable than ever to support partial binding for method implementations *even when the descriptor protocol is not involved*.

Accordingly, I suggest converting this proposal to a separate functools.partialmethod API that:

1. When called directly, passes the first positional argument as the first positional argument of the underlying function (providing call time binding of self, just like a normal function)
2. When retrieved from a class, returns itself
3. When retrieved from an instance, returns an appropriate bound method object (providing method lookup time binding of self, just like a normal function)

functools.partial will then continue to behave as it always has (thus posing no backwards compatibility risks), while the new partialmethod implementation should work with both class descriptor protocol based dispatch (through point 3) *and* the new functools.singledispatch mechanism (through point 1).
Date User Action Args
2013-06-05 04:48:41ncoghlansetrecipients: + ncoghlan, rhettinger, jcea, belopolsky, ironfroggy, jackdied, Christophe Simonis, ssadler, eckhardt, r.david.murray, Alexander.Belopolsky, anacrolix
2013-06-05 04:48:41ncoghlansetmessageid: <>
2013-06-05 04:48:41ncoghlanlinkissue4331 messages
2013-06-05 04:48:40ncoghlancreate