At 02:37 PM 3/2/04 -0500, Terry Reedy wrote: >"Armin Rigo" <arigo at tunes.org> wrote in message >news:20040301161215.GA3963 at vicky.ecs.soton.ac.uk... > > Hello, > > > > Takes 3.26s instead of just 2.64s. This is a major speed hit (20%). > >Yes. People will notice. I feel safe in predicting that an avoidable 20% >slowdown will generate 'strong' objections, especially from devotees of the >functional/recursive style. > > > On the other hand, recursive functions are not so common in Python, > >I think the frequency varies considerably depending on the problem domain >and the inductional persuasion of the programmer: iterationist vs. >recursionist vs. inbetweenist. > >While Python, with its 'for' statements, encourages the iterative form of >linear induction, branching recursion is usually much clearer that the >iterative equivalent, and Python is meant to encourage readable code. >Since branching recursion usually generates a wide but shallow (virtual) >tree of argument structures, the depth limit is usually not a problem for >such cases. It's not just recursive functions at issue. It's also: * a method that might call the same method on another instance (possibly indirectly via several other function or method calls) * a generator function that might have more than one outstanding instance * a function or method called from multiple threads ALL of these scenarios involve multiple, simultaneously-active frames for a given code object, and most are non-obvious at the point of inspection.
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