[Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

Josiah Carlson jcarlson at uci.edu
Wed Jun 14 20:26:46 CEST 2006

Boris Borcic <bborcic at gmail.com> wrote:
> Josiah Carlson wrote:
> > The closure/class example is merely a method of encapsulating state,
> > which I find easier to define, describe, and document than the closure
> > version.
> In the case of the code discussed, eg the actual model of
> def solve(problem) :
>      freebits = set(range(N))
>      def search(data) :
>          ....
>          freebits ^= swap
>      ...
>      search(initial_data)
>      ...
> the closure isn't used to encapsulate state if what you mean is passing "search" 
> around as an interface to said state - search() is only for internal consumption 
> and in fact exists only because of a quite opposite reason. Namely, the search 
> requires copying parts of the state and this is most easily expressed with a 
> recursive "search" inner function whose parameters are the copied parts.

Ok, so here's a bit of a benchmark for you.

    def helper(x,y):
        return y
    def fcn1(x):
        _helper = helper
        y = x+1
        for i in xrange(x):
            y = _helper(x,y)
    def fcn2(x):
        y = x+1
        def _helper(x):
            return y
        for i in xrange(x):
            y = _helper(x)

Can you guess which one is faster?  I guessed, but I was wrong ;).

>>> x = 1000000
>>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)])
(0.53200006484985352, 0.59299993515014648)

It turns out that passing two arguments to a helper function is actually
faster than passing one argument and pulling a second out of an
enclosing scope.

From here on out, I'll consider the speed discussion closed.

> Whatever you say, it doesn't feel adequate to me nor particularly clear to reify 
> such a recursive inner abstraction as an object method. Especially in Python, I 
> can't help reading the methods of a class declaration as intended primarily to 
> define an external interface, which is misleading in this case.

I agree.  If one is not seeking to offer an external interface, one
shouldn't, and classes may be overkill.

> I'd say a first step in convincing me I am wrong would be to show me examples of 
> object methods of the standard library that are recursive, and cut out for 
> recursion.

Actually, I don't believe that is necessary.  I've shown that you would
get better performance with a non-recursive function and passing two
arguments, than you would passing one argument with scoping tricks to
get the second.

Also, given a recursive function that provides an external interface,
I'm confident in my statement that a class would likely be more suitable,
though I agree that recursive functions without an external interface
may not be better as classes.

 - Josiah

More information about the Python-Dev mailing list