> 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.
Interestingly, here's what the summary section in PEP 309 says:
« A standard library module functional should contain an implementation
of partial, /and any other higher-order functions the community want/. »
(emphasis mine)
> 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.
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
Whether or not it is easier to read to the "average Python programmer"
is not that important I think. 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.
Regards
Antoine.
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