Christopher T King <squirrel at WPI.EDU> writes:
> On Wed, 14 Jul 2004, Michael Hudson wrote:
>
>> I guess I could have said this in c.l.py, but: what's the point? I
>> don't think I've ever had a situation where hitting the recursion
>> limit wasn't a bug, and given a) the ease with which a non-contrivedly
>> tail recursive algorithm can usually be rewritten iteratively and b)
>> the (lack of) speed of function calls in today's Python I can't see
>> any huge real advantage to this patch.
>
> To tell the truth, I don't really have any immediate use for this
> functionality, either, but since it turned out to be so easy to implement,
> I ask, "why not?" ;) Presuming it doesn't break any existing
> functionality, of course.* I prefer to think of it in the same light as
> the opcode prediction macros, i.e. as a performance enhancement, rather
> than as an attempt to introduce a new paradigm to the language (which it
> isn't).
*Is* it actually a performance enhancement?
> * I know it breaks stack traces, but the final implementation will only be
> used when the -O flag is specified, or some other such indicator is set.
It doesn't seem to me that it necessarily has to break
tracebacks... Haven't looked at the patch, though. I guess there's a
fair chance that any performance enhancements it acheives are from
resuing frame objects (if that's what it does) though.
Cheers,
mwh
--
I've even been known to get Marmite *near* my mouth -- but never
actually in it yet. Vegamite is right out.
UnicodeError: ASCII unpalatable error: vegamite found, ham expected
-- Tim Peters, comp.lang.python
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4