Message246567
| Author |
dlukes |
| Recipients |
dlukes |
| Date |
2015年07月10日.15:50:21 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
The following program makes Python 3.4.3 crash with a segmentation fault:
```
#!/usr/bin/env python3
import operator
N = 500000
l = [0]
for i in range(N):
l = map(operator.add, l, [1])
print(list(l))
```
I suppose the problem is that there are too many nested lazy calls to map, which cause a segfault when evaluated. I've played with N and surprisingly, the threshold to cause the crash varied slightly (between 130900 and 131000 on my machine).
I know that a list-comprehension, which is evaluated straight away, would be much more idiomatic for repeated element-wise addition (or numpy arrays for that matter, if available). I'm **not advocating this piece of code**, just wondering whether there couldn't be a more informative way to make Python bail out instead of the segfault? (In my real application, it took me a while to figure where the problem was without a stack trace.) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年07月10日 15:50:22 | dlukes | set | recipients:
+ dlukes |
| 2015年07月10日 15:50:22 | dlukes | set | messageid: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> |
| 2015年07月10日 15:50:22 | dlukes | link | issue24606 messages |
| 2015年07月10日 15:50:21 | dlukes | create |
|