[Python-ideas] Idea: Compressing the stack on the fly
Stephen J. Turnbull
stephen at xemacs.org
Mon May 27 07:01:03 CEST 2013
Haoyi Li writes:
> We already are not going to process billion character strings with
> iteration in python (python loops are sloooow).
Not all questions need to be answered before you ask. Mailman
archives do regularly process multigigabyte mbox files when rebuilding
an archive for some reason. This may take quite a few minutes even on
a fast box, but it's still a reasonable cost once every decade or so
(many archives never need rebuilding).
> Saying recursion is slower and more memory intensive than iteration
> (true), and thus we shouldn't think about making recursion less
> slow or less memory intensive doesn't really make much sense to me.
I think the point is more that tail recursion (where various forms of
stack compression make a lot of sense) is equivalent to iteration,
which Python does quite well in many ways. The augmented TOOWTDI
principle (with the clause "and preferably, only one") suggests that
work on optimizing tail recursion is both a YAGNI and an attractive
nuisance, given that (for Python programmers) the iterative algorithms
are equally "natural" and invariably faster and more memory-efficient.
IOW, I doubt that Guido would explicitly veto contribution of a more
efficient tail recursion as long as programs using it are equally
debuggable, and the implementation not so complex as to invite lots of
maintenance in the future. I suppose he just wants to encourage
people to spend their available effort on more Pythonic lines of
development.
More information about the Python-ideas
mailing list