Message387243
| Author | yselivanov |
|---|---|
| Recipients | Mark.Shannon, brett.cannon, gvanrossum, petr.viktorin, rhettinger, serhiy.storchaka, vstinner, yselivanov |
| Date | 2021-02-18.16:30:10 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1613665810.07.0.76841112398.issue42990@roundup.psfhosted.org> |
| In-reply-to |
| Content | |
|---|---|
> So you think that even a dedicated "LEN" opcode would not be any faster? (This is getting in Paul Sokolovsky territory -- IIRC he has a variant of Python that doesn't allow overriding builtins.) Yeah, a dedicated LEN opcode could only be faster if it would not be possible to shadow builtins (or if there was a "len" operator in Python). If that's not the case, this hypothetical LEN opcode would still have to check if "len" was shadowed or not, and that's slower than the optimized LOAD_GLOBAL we have now. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2021-02-18 16:30:10 | yselivanov | set | recipients: + yselivanov, gvanrossum, brett.cannon, rhettinger, vstinner, petr.viktorin, Mark.Shannon, serhiy.storchaka |
| 2021-02-18 16:30:10 | yselivanov | set | messageid: <1613665810.07.0.76841112398.issue42990@roundup.psfhosted.org> |
| 2021-02-18 16:30:10 | yselivanov | link | issue42990 messages |
| 2021-02-18 16:30:10 | yselivanov | create | |