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"
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