> in general, closures don't make things faster. Compared to what? Compared to doing the logic that picks which specific comparison function to call in every

> in general, closures don't make things faster. Compared to what? Compared to doing the logic that picks which specific comparison function to call in every iteration of the inner loop? Closures will certainly make things faster compared to that, for the same reason that the method described in the article does. Compared to generating bytecode by hand? Closures might not make things any faster, but they won't make them any slower either. Generating bytecode by hand is just doing by hand what the Python interpreter does internally when you define a closure using normal Python code. The def statement means the interpreter generates bytecode from the contents of the def block, wraps it in a code object, and attaches that code object to the function that gets returned. In other words, what the article is doing is generating a closure--just doing it in a way that's much less common than just writing a Python function that returns a function. > It would be necessary to look up the closed-over value in the nonlocal environment No, it wouldn't. A Python closure includes cells that store the values of the closed over variables, so as far as the closure function is concerned, they're local variables.