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.
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'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.
Regards,
Boris Borcic
--
"On naît tous les mètres du même monde"
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
