PEP 309 was written, discussed, approved, and implemented - that's how partial ended up in the stdlib.
Ok, I'm surprised that a single addition to a module needed a PEP in order to be approved.
A PEP is generally needed if there is no easy consent achievable. It's not (primarily) the size of a feature that determines the need for a formal process, but but whether the community considers a certain change "obviously" correct and desirable.
def foo(data): return compose(a, b(data), c)
Ok, here's my attempt without looking at the patch:
def foo(data): def bar(*args, **kwargs): return a(b(data)(c(*args, **kwargs))) return bar
Ok, that's also what the patch has proposed. I was puzzled when I read
l.sort(key=compose(itemgetter(1), itemgetter(0))))
because I expected it to mean
l.sort(key=lambda x:x[1][0])
when it would really mean
l.sort(key=lambda x:x[0][1])
Whether or not it is easier to read to the "average Python programmer" is not that important I think.
I completely disagree. It is one of Python's strength that it is "executable pseudo-code", which originates from the code being easy to read, and meaning the obvious thing even to a reader not familiar with the language. The proposed compose function breaks this important property, in a way that allows misinterpretation (i.e. you think you know what it does, and it actually does something different).
I, personally, was not able to understand the compose function correctly, so I remain opposed.
We have lots of things that certainly aren't, and yet still exist (all of the functions in the operator module, for example; or `partial` itself for that matter). They are there for advanced programmers.
It's quite ok if only advanced programmers know that they are there, and know how to write them. However, I still think it is desirable that "lesser" programmers are then able to read them, or atleast notice that they mean something that they will need to learn first (such as a keyword they had never seen before).
Regards, Martin