This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2020年08月12日 15:42 by hroncok, last changed 2022年04月11日 14:59 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 21850 | merged | pablogsal, 2020年08月12日 18:33 | |
| PR 21853 | closed | miss-islington, 2020年08月13日 08:49 | |
| PR 22105 | closed | miss-islington, 2020年09月04日 22:34 | |
| PR 22107 | merged | miss-islington, 2020年09月04日 22:38 | |
| Messages (9) | |||
|---|---|---|---|
| msg375255 - (view) | Author: Miro Hrončok (hroncok) * | Date: 2020年08月12日 15:42 | |
Consider this reproducer.py:
import sys
LEN = int(sys.argv[1])
with open('big_dict.py', 'w') as f:
print('INTS = {', file=f)
for i in range(LEN):
print(f' {i}: None,', file=f)
print('}', file=f)
import big_dict
assert len(big_dict.INTS) == LEN, len(big_dict.INTS)
And run it with any number > 65535:
$ python3.9 reproducer.py 65536
Traceback (most recent call last):
File "/tmp/reproducer.py", line 12, in <module>
assert len(big_dict.INTS) == LEN, len(big_dict.INTS)
AssertionError: 65535
This has not happened on python 3.8. This also happens with PYTHONOLDPARSER=1.
|
|||
| msg375256 - (view) | Author: Zbyszek Jędrzejewski-Szmek (zbysz) * | Date: 2020年08月12日 15:45 | |
Also reproduces with today's git. |
|||
| msg375257 - (view) | Author: Miro Hrončok (hroncok) * | Date: 2020年08月12日 15:50 | |
It appears that the 65535 key is missing regardless of the LEN value. |
|||
| msg375259 - (view) | Author: Zbyszek Jędrzejewski-Szmek (zbysz) * | Date: 2020年08月12日 16:08 | |
Bisect says 8a4cd700a7426341c2074a2b580306d2d60ec839 is the first bad commit. Considering that 0xFFFF appears a few times in that patch, that seems plausible ;) |
|||
| msg375275 - (view) | Author: Matthew Barnett (mrabarnett) * (Python triager) | Date: 2020年08月12日 18:07 | |
I think what's happening is that in 'compiler_dict' (Python/compile.c), it's checking whether 'elements' has reached a maximum (0xFFFF). However, it's not doing this after incrementing; instead, it's checking before incrementing and resetting 'elements' to 0 when it should be resetting to 1. The 65535th element isn't counted. |
|||
| msg375295 - (view) | Author: Mark Shannon (Mark.Shannon) * (Python committer) | Date: 2020年08月13日 08:48 | |
New changeset c51db0ea40ddabaf5f771ea633b37fcf4c90a495 by Pablo Galindo in branch 'master': bpo-41531: Fix compilation of dict literals with more than 0xFFFF elements (GH-21850) https://github.com/python/cpython/commit/c51db0ea40ddabaf5f771ea633b37fcf4c90a495 |
|||
| msg375296 - (view) | Author: Mark Shannon (Mark.Shannon) * (Python committer) | Date: 2020年08月13日 09:00 | |
@hroncok, How did you discover this issue? I'd like to clean up the code for creating dictionary literals and it might be helpful to know where such huge dictionary literals exist. I'm guessing that they are used as lookup tables for things like Unicode code-point tables, and that they would only include constants. |
|||
| msg375297 - (view) | Author: Karthikeyan Singaravelan (xtreak) * (Python committer) | Date: 2020年08月13日 09:03 | |
@hroncok said on Twitter it was reported at https://github.com/Storyyeller/enjarify/issues/17 |
|||
| msg376417 - (view) | Author: Pablo Galindo Salgado (pablogsal) * (Python committer) | Date: 2020年09月04日 23:38 | |
New changeset d64d78be20ced6ac9de58e91e69eaba184e36e9b by Miss Islington (bot) in branch '3.9': bpo-41531: Fix compilation of dict literals with more than 0xFFFF elements (GH-21850) (GH-22107) https://github.com/python/cpython/commit/d64d78be20ced6ac9de58e91e69eaba184e36e9b |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:59:34 | admin | set | nosy:
+ lukasz.langa github: 85703 |
| 2020年09月04日 23:39:20 | pablogsal | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2020年09月04日 23:38:58 | pablogsal | set | messages: + msg376417 |
| 2020年09月04日 22:38:51 | miss-islington | set | pull_requests: + pull_request21192 |
| 2020年09月04日 22:34:39 | miss-islington | set | pull_requests: + pull_request21190 |
| 2020年08月13日 09:03:38 | xtreak | set | messages: + msg375297 |
| 2020年08月13日 09:00:13 | Mark.Shannon | set | messages: + msg375296 |
| 2020年08月13日 08:49:09 | miss-islington | set | nosy:
+ miss-islington pull_requests: + pull_request20980 |
| 2020年08月13日 08:48:53 | Mark.Shannon | set | messages: + msg375295 |
| 2020年08月12日 18:34:18 | batuhanosmantaskaya | set | nosy:
+ batuhanosmantaskaya |
| 2020年08月12日 18:33:26 | pablogsal | set | keywords:
+ patch nosy: + pablogsal pull_requests: + pull_request20978 stage: patch review |
| 2020年08月12日 18:07:00 | mrabarnett | set | nosy:
+ mrabarnett messages: + msg375275 |
| 2020年08月12日 17:22:00 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka components: + Interpreter Core |
| 2020年08月12日 16:52:27 | eric.smith | set | nosy:
+ eric.smith |
| 2020年08月12日 16:22:24 | vstinner | set | keywords: + 3.9regression |
| 2020年08月12日 16:22:18 | vstinner | set | priority: normal -> release blocker |
| 2020年08月12日 16:17:22 | hroncok | set | versions: + Python 3.10 |
| 2020年08月12日 16:09:09 | ammar2 | set | nosy:
+ Mark.Shannon |
| 2020年08月12日 16:08:28 | zbysz | set | messages: + msg375259 |
| 2020年08月12日 15:56:21 | xtreak | set | nosy:
+ xtreak |
| 2020年08月12日 15:50:19 | hroncok | set | messages: + msg375257 |
| 2020年08月12日 15:45:10 | zbysz | set | nosy:
+ zbysz messages: + msg375256 |
| 2020年08月12日 15:42:56 | hroncok | create | |