Then I wonder how partial() ended up in the stdlib.
PEP 309 was written, discussed, approved, and implemented - that's how partial ended up in the stdlib. The feature itself might be debatable, that's what we have the PEP process for.
Either we decide it is useful to have a set of basic "functional" tools in the stdlib, and both partial() and compose() have their place there, or we decide functools has no place in the stdlib at all. Providing a half-assed module is probably frustrating to its potential users.
So write a PEP and propose to enhance the standard library.
(not being particularly attached to functional tools, I still think compose() has its value, and Jason did a good job of presenting potential use cases)
I don't think he did. Comparing it to the one obvious solution (use a lambda expression), his only reasoning was "it is much easier to read". I truly cannot believe that a compose function would be easier to read to the average Python programmer: if you have
def foo(data): return compose(a, b(data), c)
what would you expect that to mean? Please rewrite it as a regular Python expression, preferably without looking at the patch that has been proposed first. I bet there is a 50% chance that you get it wrong (because there are two possible interpretations).
Regards, Martin