This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Jason.Baker, eric.araujo, ncoghlan, rhettinger
Date 2011-01-26.02:42:00
SpamBayes Score 1.0460566e-08
Marked as misclassified No
Message-id <>
For flip, const and identity I agree there are already better ways to handle them using either itertools or comprehension syntax.

The problem I have with trampoline is that it depends on the function's *return values* being defined in a certain way (i.e. returning a zero-argument callable instead of just calling them).

The other major factor limiting the appeal of some of the more complex functional programming tools (the one that almost lead to lambda's removal in 3.x) is the availability of nested function definitions.

To rephrase Raymond's last example in more idiomatic Python:

def fg2(x):
  # Comment or docstring explaining fg2
  return f(g(2,x)

def h2(x, y):
  # Comment or docstring explaining h2
  return h(x, 3, y, flag=True)

result = [fg2(x), h2(x, y) for x, y in zip(X, Y) if x>y//2]

I see compose as being the most potential useful, as it would allow us to provide a C accelerated version of the following alternative to trampoline:

def compose(*args):
  def _composed(x):
    for f in args:
      x = f(x)
    return x
  return _composed

While this actually does match the mathematical definition, I agree pointing that out is more confusing than helpful for many people (since the "inside-out" nested evaluation ends up looking like "right-to-left" evaluation when written down)

Raymond's proposed alternative to trampoline could then be written:

Date User Action Args
2011-01-26 02:42:00ncoghlansetrecipients: + ncoghlan, rhettinger, eric.araujo, Jason.Baker
2011-01-26 02:42:00ncoghlansetmessageid: <>
2011-01-26 02:42:00ncoghlanlinkissue11011 messages
2011-01-26 02:42:00ncoghlancreate