I disagree with the proposal. (And with taking one hour between a proposal and merge.)
The plan to remove ARRAY in 3.15 goes against PEP 387:
If the expected maintenance overhead and security risk of the deprecated behavior is small (e.g. an old function is reimplemented in terms of a new, more general one), it can stay indefinitely (or until the situation changes).
(I'll note that this clarification got added a few days after this proposal, though.)
The function is two lines long, and has tests. It has no maintenance overhead or additional security risk.
It's also used in third-party projects (some of which test with alphas/betas and have now switched to multiplication).
I propose to restore it and soft-deprecate instead. Would you be OK with that, @vstinner?
As for SetPointerType, yeah, no one should be using that, and hardly anyone is.
Activity
pythongh-105733: Deprecate ctypes SetPointerType() and ARRAY()
pythongh-105733: Deprecate ctypes SetPointerType() and ARRAY()
gh-105733: Deprecate ctypes SetPointerType() and ARRAY() (#105734)
pythongh-105733: Fix ctypes What's New entry
gh-105733: Fix ctypes What's New entry (#106576)
MAINT: Replace deprecated ctypes.ARRAY(item_type, size) with item_typ…
encukou commented on Jul 25, 2024
I disagree with the proposal. (And with taking one hour between a proposal and merge.)
The plan to remove ARRAY in 3.15 goes against PEP 387:
(I'll note that this clarification got added a few days after this proposal, though.)
The function is two lines long, and has tests. It has no maintenance overhead or additional security risk.
It's also used in third-party projects (some of which test with alphas/betas and have now switched to multiplication).
I propose to restore it and soft-deprecate instead. Would you be OK with that, @vstinner?
As for SetPointerType, yeah, no one should be using that, and hardly anyone is.
encukou commented on Jul 25, 2024
(anecdotally: at EuroPython I've seen a person use ARRAY in the REPL. This is not worth them re-learning how to make array types.)
vstinner commented on Jul 27, 2024
I didn't see any complain about the deprecation apart from you. I don't see the benefits of keeping two ways to create an array. PEP 20 says:
A code search on PyPI top 7,500 projects only finds 2 lines:
The first one is stupid, ctypes.ARRAY(3, 2) returns 6... The first parameter must be a ctypes type, not an integer.
picnixz commented on Jul 28, 2024
There are a bit more usages on GitHub: https://github.com/search?q=%2F%28%3F-i%29ctypes%5C.ARRAY%5C%28%2F&type=code (but some of them are CPython but I found a bit more normal usages that are not 7 years old)
encukou commented on Jul 29, 2024
So it's PEP 20 against PEP 387, or your opinion against mine :(
JelleZijlstra commented on Jul 29, 2024
I would favor keeping ARRAY, since there is little maintenance cost involved and removing it would break at least some users.
picnixz commented on Jul 29, 2024
I personally like ARRAY because it tells you that are you are creating an array (visually speaking)
vstinner commented on Jul 29, 2024
Oh right. Let's keep ARRAY(). But I would suggest to simply remove the deprecation in this case, no need to soft deprecate it if we keep it.
encukou commented on Jul 29, 2024
I'm for soft deprectation, because it tells you which of the two ways to do it is the obvious one :)
gh-105733: Soft-deprecate ctypes.ARRAY, rather than hard-deprecating …
pythongh-105733: Soft-deprecate ctypes.ARRAY, rather than hard-deprec…
[3.13] gh-105733: Soft-deprecate ctypes.ARRAY, rather than hard-depre…
picnixz commented on Jul 30, 2024
Closing since completed in #122281.
pythongh-105733: Soft-deprecate ctypes.ARRAY, rather than hard-deprec…