3 ms·
This seems like a cleverly crafted satire reply, rather than an actual complaint about python.
by Epokhe 4y ago
This seems like a cleverly crafted satire reply, rather than an actual complaint about python.
- iudqnolq 4y agoIf so, it's a bit misleading. The go bug just requires a reference, rather than a lambda. I bucket lambdas into a category of language features I expect to have more sharp edges around capture semantics than references. Bug: var all []*Item for _, item := range items { all = append(all, &item) } Fix: var all []*Item for _, item := range items { item := item all = append(all, &item) }
- BoppreH 4y agoI assure you it's not satire, otherwise it wouldn't be such a popular question on StackOverflow[1] and an item in the Python FAQ[2] [1]: https://stackoverflow.com/questions/2295290/what-do-lambda-function-closures-capture https://stackoverflow.com/questions/2295290/what-do-lambda-f... [2]: https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result https://docs.python.org/3/faq/programming.html#why-do-lambda...
- Epokhe 4y agoYeah, makes sense that it's popular. I just thought you were making a joke by creating a similar looking issue with a different underlying reason. In Go example the issue happens because item variable is per-loop, in your python example the issue is not related to loops at all, it's just because functions capture the value of global variables at execution time. And the cherry on top is that the solution is also similar looking(i=i), but working with a different mechanic underneath(default argument assignment). Anyway, this was my perspective that led me to interpret this as satire. A bit disappointed haha