[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