Timeline for answer to List comprehension vs map by user541686
Current License: CC BY-SA 4.0
Post Revisions
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2025 at 7:39 | comment | added | NeilG | Or maybe just use unique variable names? Like, ... yeah. | |
| Nov 29, 2021 at 23:15 | comment | added | Maxim Egorushkin |
I never had this problem, today I learned. Performance-wise, on 2021年11月29日 in Ubuntu 20.04 LTS, Python 3.8 map is 7x faster on the first original timeit example and 3.5x on the second.
|
|
| Jun 20, 2020 at 9:12 | history | edited | Community Bot |
Commonmark migration
|
|
| Sep 19, 2019 at 18:54 | comment | added | franksands | @Mehrdad Actually I got this habit when coding in Java many years ago. As for running out of variable names, I never had more than 3 nested loops. Also, I avoid using i, j, k. I prefer descriptive names like "for book in books" and etc | |
| Sep 19, 2019 at 18:45 | comment | added | user541686 |
@franksands: You only find it "best" because of this massive pitfall, which is kind of the point. Otherwise it's pretty ridiculous to have for i, for j, for k, for l in completely disjoint iterators just to avoid reusing variable names, and you very quickly run out of reasonable variable names that way. Which you can avoid if you don't use comprehensions.
|
|
| Sep 19, 2019 at 18:38 | comment | added | franksands | Hi I'm reading this in 2019, and still use Python 2 at work. However, I think the code in the example is not very good since you're shadowing the variable x in the list comprehension. In my opinion it's always best to use different variables for each iterator | |
| S Jul 19, 2019 at 18:21 | history | suggested | mic | CC BY-SA 4.0 |
Note that answer is for Python 2 (https://meta.stackoverflow.com/questions/265433/good-question-old-version-dependent-answer/265440#265440)
|
| Jul 19, 2019 at 18:19 | review | Suggested edits | |||
| S Jul 19, 2019 at 18:21 | |||||
| Jan 6, 2019 at 23:46 | comment | added | WestCoastProjects |
where is imap and ifilter ?
|
|
| Jul 9, 2014 at 13:43 | history | edited | Paolo Moretti | CC BY-SA 3.0 |
fixed typo
|
| Dec 18, 2013 at 1:51 | comment | added | user541686 |
@wim: Well I mean if you disagree then you disagree, there's not much I can do except counter your points. Regarding the generator, it's still not any better because the list has to undergo lots of reallocations (whereas map knows how long the list will be a priori). Frankly, if you're using a generator then you should be using imap, not map, which changes the question entirely. But if you just want to find a reason to pick on the answer then just keep your downvote... I don't have much else to say honestly.
|
|
| Dec 18, 2013 at 1:39 | comment | added | wim |
It is still not a logical reason for switching to map and/or filter. If anything, the most direct and logical translation to avoid your problem is not to map(lambda x: x ** 2, numbers) but rather to a generator expression list(x ** 2 for x in numbers) which doesn't leak, as JeromeJ has already pointed out. Look Mehrdad, don't take a downvote so personally, I just strongly disagree with your reasoning here.
|
|
| Dec 18, 2013 at 0:38 | comment | added | user541686 | @wim: Huh? Python 2 is still used in a lot of places, the fact that Python 3 exists doesn't change that. And when you say "it's not exactly a subtle bug for anyone that has used Python more than a few months" that sentence literally means "this only concerns inexperienced developers" (clearly not you). And for the record, you clearly didn't read the answer because I said in bold that I was moving, not copying, code. Copy-paste bugs are pretty uniform across languages. This kind of bug is more unique to Python because of its scoping; it's subtler & easier to forget about and miss. | |
| Dec 18, 2013 at 0:14 | comment | added | wim | I'm sorry but you wrote this in late 2012, well after python 3 is on the scene, and the answer reads like you're recommending an otherwise unpopular style of python coding just because you got bitten by a bug while cutting-and-pasting code. I never claimed to be bright or experienced, I just don't agree that the bold claim is justified by your reasons. | |
| Dec 17, 2013 at 23:48 | comment | added | user541686 | @wim: This was only about Python 2, although it applies to Python 3 if you want to stay backwards-compatible. I knew about it and I'd been using Python for a while now (yes, more than just a few months), and yet it happened to me. I've seen others who are smarter than me fall into the same trap. If you're so bright and/or experienced that this isn't a problem for you then I'm happy for you, I don't think most people are like you. If they were, there wouldn't be such an urge to fix it in Python 3. | |
| Dec 17, 2013 at 23:39 | comment | added | wim | In my opinion, this one reason is a petty example for making such a bold claim in the first line. It's a completely invalid rationale in python 3, and even in 2.x it is not exactly a subtle bug for anyone that has used python more than a few months. It's probably the most well-known trap, after the mutable default | |
| Aug 21, 2013 at 21:35 | comment | added | jeromej |
Or always use generator and when you cannot, you could still use list(x+2 for x in objs). Right?
|
|
| Nov 21, 2012 at 19:24 | history | edited | user541686 | CC BY-SA 3.0 |
added 134 characters in body
|
| Nov 21, 2012 at 19:00 | comment | added | TimothyAWiseman | Thanks for pointing this out. It hadn't explicitly occurred to me that list comprehension was in the same scope and could be an issue. With that said, I think some of the other answers make it clear that list comprehension should be the default approach most of the time but that this is something to remember. This is also a good general reminder to keep functions (and thus scope) small and have thorough unit tests and use assert statements. | |
| Nov 20, 2012 at 22:34 | history | edited | user541686 | CC BY-SA 3.0 |
added 81 characters in body
|
| Nov 20, 2012 at 22:28 | history | answered | user541686 | CC BY-SA 3.0 |