[Python-Dev] PEP 309

[Raymond Hettinger]

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

-0  My preference is that it not go in as-is.  

It is better to teach how to write a closure than to introduce a new
construct that has its own problems and doesn't provide a real
improvement over what we have now.  Despite my enthusiasm for functional
programming and the ideas in PEP, I find the PFA implementation
annoying.

I had tried out the implementation that was being pushed for Py2.4 and
found it wanting.  Hopefully, it has improved since then.  Here are a
few thoughts based on trying to apply it to my existing code.

* The PFA implementation proposed for Py2.4 ran slower than an
equivalent closure.  If the latest implementation offers better
performance, then that may be a reason for having it around.

* Having PFA only handle the first argument was a PITA with Python.  In
Haskell and ML, function signatures seems to have been designed with
argument ordering better suited for left curries.  In contrast, Python
functions seem to have adverse argument ordering where the variables you
want to freeze appear toward the right.  This is subjective and may just
reflect the way I was aspiring to use "partial" to freeze options and
flags rather than the first argument of a binary operator.  Still, I
found closures to be more flexible in that they could handle any
argument pattern and could freeze more than one variable or keyword at a
time.

* The instance method limitation never came up for me.  However, it
bites to have a tool working in a way that doesn't match your mental
model.  We have to document the limitations, keep them in mind while
programming, and hope to remember them as possible causes if bugs ever
arise.  It would be great if these limitations could get ironed out.

* Using the word "partial" instead of "lambda" traded one bit of
unreadability for another.  The "lambda" form was often better because
it didn't abstract away its mechanism and because it supported more
general expressions.  I found that desk-checking code was harder because
I had to mentally undo the abstraction to check that the argument
signature was correct.

* It is not clear that the proposed implementation achieves one of the
principal benefits laid out in the PEP:  "I agree that lambda is usually
good enough, just not always. And I want the possibility of useful
introspection and subclassing."

If we get a better implementation, it would be nice if the PEP were
updated with better examples.  The TkInter example is weak because we
often want to set multiple defaults at the same time (foreground,
background, textsize, etc) and often those values are config options
rather than hardwired constants.


Raymond