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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
