[Python-Dev] PEP 309 enhancements

[Paul Moore]

On Sat, 26 Feb 2005 16:50:06 +1000, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
> Moving a discussion from the PEP309 SF tracker (Patch #941881) to here, since
> it's gone beyond the initial PEP 309 concept (and the SF tracker is a lousy
> place to have a design discussion, anyway).
> 
> The discussion started when Steven Bethard pointed out that partial objects
> can't be used as instance methods (using new.instancemethod means that the
> automatically supplied 'self' argument ends up in the wrong place, after the
> originally supplied arguments).
[...]
> However, this breaks down for nested partial functions - the call to the nested
> partial again moves the 'self' argument to after the originally supplied
> argument list. This can be addressed by automatically 'unfolding' nested
> partials (which should also give a speed benefit when supplying arguments
> piecemeal, since building incrementally or all at once will get you to the same
> place):
[...]
> At this point, the one thing you can't do is use a partial function as a *class*
> method, as the classmethod implementation doesn't give descriptors any special
> treatment.

While I see a theoretical need for this functionality, I don't know of
a practical use case. PEP 309 is marked as accepted in its current
form, and has an implementation in C (which appears to be justified on
speed grounds - see the SF tracker). The new code is in Python - if
it's to be included, then at *some* stage it needs translating to C.

Personally, I'd rather see partial as it stands, with its current
limitations, included. The alternative seems to be a potentially long
discussion, petering out without conclusion, and the whole thing
missing Python 2.5. (I know that's a long way off, but this already
happened with 2.4...)

> So, instead of the above, I propose the inclusion of a callable 'partialmethod'
> descriptor in the functional module that takes the first positional argument
> supplied at call time and prepends it in the actual function call (this still
> requires automatic 'unfolding'in order to work correctly with nested partial
> functions):

No problem with this, as long as:

1. An implementation (which needs to work alongside the existing C
code) is provided
2. PEP 309 is updated to include an explanation of the issue and a
justification for this solution.
3. The documentation is updated to make it clear why there are two
callables, and which to use where. (That could be difficult to explain
clearly - I understand some of the issues here, but just barely - the
docs would need to be much clearer).

Personally, I feel this classifies as YAGNI (whereas, I'd use the
current partial a *lot*).

OTOH, I think the fact that the existing partial can't be used as an
instance method does deserve mention in the documentation, regardless.
For that your explanation (quoted above, and repeated here) would
suffice:

"""
partial objects can't be used as instance methods (using
new.instancemethod means that the automatically supplied 'self'
argument ends up in the wrong place, after the originally supplied
arguments)
"""

Paul.