4 ms·
I think you're looking at Python 2, because in py3 the list comprehensions create a nested scope for the loop variable to be local in. -- i.e. 'i' would be in a
by abecedarius 8y ago
I think you're looking at Python 2, because in py3 the list comprehensions create a nested scope for the loop variable to be local in. -- i.e. 'i' would be in a local environment, not in globals. This doesn't change the behavior of these particular closures, since i is still mutated in the loop.
- UncleEntity 8y agoPython 3.6.5 (default, Apr 4 2018, 15:01:18) ...even weirder: >>> fs[0].__closure__ == fs[1].__closure__ True
- abecedarius 8y agoSince I don't have py3 installed at the moment, I can't check anything, but I'd guess this is two closures with distinct ids but the same environments, and == is doing a structural comparison rather than an identity comparison. Wish I could look into it right now.
- UncleEntity 8y ago>>> fs[0].__closure__, fs[1].__closure__ ((<cell at 0x7f4e9111b048: int object at 0x7f4e98e99500>,), (<cell at 0x7f4e9111b048: int object at 0x7f4e98e99500>,)) So lambda isn't broken it's the list comprehension going all wonky with its local variables methinks.
- abecedarius 8y agoAll right, I looked into this using repl.it. The __closure__ field is not actually a closure in the usual sense of the word -- it's the environment of the closure, and fs[0] and fs[1] are expected to share the same environment. If you look at the identities of fs[0] and fs[1] themselves, they are different. It's as I said originally, just with a confusing name for the environment field.