I am personally indifferent to this, even though I had in mind in PEP309, that compose would probably end up in there too. On the one hand, some people will keep on expecting it to be there. The ones that care about it will not be confused: they'll expect compose(f,g)(x) to be f(g(x)) as is proposed. It can't do any significant harm. On the other hand it's not likely to be used even as often as partial, which I always wanted mostly to make anonymous callables for Tkinter, not because of any ivory-tower functional programming bias. And the most common use case of compose() is covered by a one-liner that really doesn't need to be in the standard library. I'll say +0, with the + because if new Python programmers run across compose() in the docs, and aren't familiar with the idea, they can follow a link from there to Wikipedia, and maybe it will give them an idea we haven't thought of for something cool to do with it. Peter Harris
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4