bpo-32782: PEP3118 itemsize of an empty ctypes array should not be 0 #5576
Conversation
eric-wieser
force-pushed
the
ctypes-empty-array-itemsize
branch
2 times, most recently
from
147ab7d
to
4383b40
Compare
eric-wieser
force-pushed
the
ctypes-empty-array-itemsize
branch
from
4383b40
to
7b4c122
Compare
eric-wieser
changed the title
|
@pv: Since you've made PEP3118 patches to cpython before, would you mind reviewing this? |
eric-wieser
force-pushed
the
ctypes-empty-array-itemsize
branch
from
7b4c122
to
29b3c32
Compare
|
LGTM the test failures do not seem related to this pull request |
|
@mattip: Can you approve via github so that this goes through the process automation that's set up? |
|
Re-opening to restart the tests |
terryjreedy
added
needs backport to 3.7
type-bug
|
Tests for empty arrays of floats and doubles are added. My naive question is this: The PEP suggests that itemsize should cache the return from PyBuffer_SizeFromFormat. Was that function actual added? Can it be used? |
|
I can't find an reference to At any rate, ctypes knows the size without having to resort to string parsing |
|
| Name | Link |
|---|---|
| accc969 | |
| https://app.netlify.com/sites/python-cpython-preview/deploys/639bb2ef300d190009b736b6 |
|
@mdickinson, I see you recently reviewed some ctypes PRs; would you mind taking a quick look at this one? |
|
@eric-wieser Will do. It might take me a few days to get to it. |
LGTM, and works as expected on my machine (confirmed that the new unit tests fail before the fix and pass afterward). I'm wondering whether we should upgrade the asserts in PyCData_itemtype to use Py_FatalError instead. I was unable to convince myself that there was no possibility of stg_dict being NULL on this code path.
mdickinson
added
the
|
If you want to schedule another build, you need to add the |
bedevere-bot
removed
the
|
Thanks for testing! Given this file has 52 asserts (11 on std_dict) and no Is that ok? |
|
Edit: nevermind, results are here |
Yep, seems reasonable. Buildbot failures look unrelated. Merging. |
|
Thanks @eric-wieser for the PR, and @mdickinson for merging it |
|
Thanks @eric-wieser for the PR, and @mdickinson for merging it |
|
GH-100451 is a backport of this pull request to the 3.10 branch. |
…be 0 (pythonGH-5576) The itemsize returned in a memoryview of a ctypes array is now computed from the item type, instead of dividing the total size by the length and assuming that the length is not zero. (cherry picked from commit 84bc6a4) Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
|
GH-100452 is a backport of this pull request to the 3.11 branch. |
…be 0 (pythonGH-5576) The itemsize returned in a memoryview of a ctypes array is now computed from the item type, instead of dividing the total size by the length and assuming that the length is not zero. (cherry picked from commit 84bc6a4) Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
… be 0 (GH-5576) (#100451) gh-76963: PEP3118 itemsize of an empty ctypes array should not be 0 (GH-5576) The itemsize returned in a memoryview of a ctypes array is now computed from the item type, instead of dividing the total size by the length and assuming that the length is not zero. (cherry picked from commit 84bc6a4) Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
… be 0 (GH-5576) (GH-100452) gh-76963: PEP3118 itemsize of an empty ctypes array should not be 0 (GH-5576) The itemsize returned in a memoryview of a ctypes array is now computed from the item type, instead of dividing the total size by the length and assuming that the length is not zero. (cherry picked from commit 84bc6a4) Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
The itemsize should be computed from the item type, not by dividing the total size by the length and assuming that the length is not zero.
The tests already expected this behavior, they were just missing the test-case needed to trigger it.
https://bugs.python.org/issue32782
(fixes #76963)