> 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
_______________________________________________
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
