Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
Some of these have been proposed and rejected before.
Compose has a problematic API because the traditional order of application in
mathematics is counter-intuitive for many people.
Const seems reasonable except that we already have ways to do it:
twos = lambda :2
twos = itertools.repeat(2).__next__
The principal use case for const is with map() and itertools.repeat() is
already targeted at that use-case:
cubes = list(map(pow, range(10), repeat(3)))
Flip would be nice on occasion:
colorseq = list(map(flip, enumerate(
'red orange yellow green blue indigo violet'.split())))
Identity is problematic for a few reasons. First, there doesn't seem to be one
signature that fits all use cases:
identity1 = lambda *args: *args # always returns a tuple
identity2 = lambda arg: arg # always returns a scalar
Also, the availability of 'identity' seems to encourage bad design.
Speedwise, it is usually better to have two paths (predicate is None vs some
given predicate) than have an identity function default (predict=identity).
See the itertools module for examples.
Trampoline is interesting, but the use case doesn't seem to arise much in
Python programming and when it does, it is usually clearer to write:
for f in get_actions():
f()
That straight-forward code is superior, not just because of its readability but
also because it is easily modified to handle return values being feed in to
consecutive calls, adding optional and keyword arguments, introducing logging,
etc.
In short, some of these constructs are better suited for languages that a more
purely functional in nature. Those don't treat scalar arguments differently
than multiple arguments, those don't use keywords or optional arguments,
currying can be done cleanly etc.
Experiences with the itertools module have shown than not all of the usual
favorite functional gizmos fit well in the Python language. They are tempting
toys, but typically don't beat regular, clean Python code.
One last comment, any time a group of interoperative tools is proposed, I think
it absolutely necessary to construct a bunch of sample code to exercise the
APIs working in concert with one another. With the itertools module,
considerable effort was directed at designing a toolkit with cleanly
interoperative parts.
Also, when proposing something that changes the fundamentals of how people
would design their programs, I think it is necessary to scan real-world code to
find many examples where the code would be much improved if it used the new
constructs. (This is similar to the notion of a Phase III clinical trial --
even if something works, it needs to be shown to be better than existing
alternatives).
----------
nosy: +rhettinger
versions: -Python 3.2
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
