[Python-Dev] PEP 309 enhancements

[Nick Coghlan]

Paul Moore wrote:
> 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...)

Yes - I certainly don't think this is a reason to hold off checking in what we 
already have. The only question is whether or not it gets tweaked before the 
first 2.5 alpha.

>>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

That's the plan - the Python code is just the easiest way to make the intended 
semantics clear for the discussion.

> 2. PEP 309 is updated to include an explanation of the issue and a
> justification for this solution.

Seems like the most sensible place to record it for posterity (assuming we 
actually end up doing anything about it)

> 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).

The basic concept is that if you're building a partial function in general, use 
'partial'. If you're building an instance method or class method (i.e. the two 
cases where Python automatically provides the first argument), use 
'partialmethod', because the standard 'partial' generally won't do the right 
thing with the first argument.

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

I can certainly appreciate that point of view. It's a rather large conceptual 
hole though, so if it can be plugged elegantly, I'd like to see that happen 
before 2.5 goes live.

> 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)
> """

The distinction is actually finer than that - it can work in some cases, 
provided the predefined arguments are all given as keyword arguments rather than 
positional arguments.

The real issue is that there may be situations where you don't have control over 
how the function you want to turn into an instance method was created, and if 
someone has used partial with positional arguments to create the function, you 
may have no practical way out. 'partialmethod' fixes that - it allows creating a 
partial function which expects the next positional argument to be the first 
argument to the underlying function, while remaining positional arguments are 
appended as usual.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net