PEP 255: Simple Generators

[Tim Peters]

[David Eppstein]
> ...
> Why is tail recursion somehow unPythonlike?

It's not, where it's appropriate -- but it's not appropriate in Python
nearly as often as in languages like Scheme or Haskell.  It starts with the
builtin collection types:  Python lists (and tuples) aren't cons cells,
they're contiguous vectors, and so for-loops are the *natural* way to
process them.  Tail-recursion is pretty much insane for that in Python, as
processing list[0] then recursing on list[1:] turns a speedy task into a
quadratic-time mess.  Then, as below, so above <wink>.

> Or, more to the point, why should it remain that way?

Most Python programmers use tail recursion rarely or never, so there's
little demand to change it.  There's also no volunteer to work on it.

> If it's merely that it is implemented inefficiently (i.e. piling up
> unnecessary stack frames)

When something raises an uncaught exception, "unnecessary" become highly
debatable (thinking of the diagnostic traceback here, and of the debugger).
Python's WYSIWYG tracebacks are an important feature; "losing frames" to
tail-recursion optimization would likely need to be optional, and disabled
by default, because of this.

> then that can be fixed, no?

It hasn't been yet, and the prospects are nil in the absence of a PEP.