You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove deprecated and undocumented function ctypes.SetPointerType #133866
Yes, you should remove the underlying C implementation as well.
I'm not entirely sure I can do it. We only communicated that the Python interface is deprecated, not the C one (even if this should not be used). cc @vstinner@encukou.
(I'm however in favor of doing it, just that I don't know if we can do it without an explicit notice)
set_type set proto for pointer type, that used in lot of places. Also, it will break external users like pyglet who implements IUnknown interface with _type_.
Yes, we'll need to deprecate set_type, and its C implementation, separately; in 3.15.
Now that __pointer_type__ is in, it should be possible to replace set_type by the new API, in all use cases we're aware of. But let's give users time to report other use cases.
I'm trying to reduce this a little bit. I'm not sure if it only triggers on 3.14 or if it's possible on 3.15 as well. The CFFI CI was using free-threaded 3.14.3.
SetPointerType was implemented using set_type, and we discussed above that it would be good to deprecate set_type. But you're right that it's a different matter.
It makes sense, for the thread safety reasons. I left the issue open for that (my workflow would be to close this after opening the new one).
But I'm deferring to @ZeroIntensity now :)
Other code borrows stginfo->proto, assuming that it's set only once for a given object.
We could add a lock around this, but since set_type is unneeded*, undocumented, and as far as I can see essentially unused, it's probably better to get rid of set_type & stick to single assignment for stginfo->proto.
* for background on the use case: the need for SetPointerType/set_type -- "filling in" a pointer's type after creation -- is mentioned in ctypes 0.6.3+ docs (and earlier with a note that it “doesn't seem to work completely”). In 0.9.9.6 -- just before merging ctypes to stdlib -- the tutorial was updated: this use case is served by struct/union _fields_ being “lazy“.
Activity
kumaraditya303 commentedon May 11, 2025
+1 to remove
SetPointerTypeas it is not thread safe too and can crash as the uses ofinfo->protouse borrowed reference.picnixz commentedon May 11, 2025
Oh, do you mean that no one use should be using it? in this case, I'll remove the
use set_type instead.kumaraditya303 commentedon May 11, 2025
Yes, you should remove the underlying C implementation as well.
picnixz commentedon May 11, 2025
I'm not entirely sure I can do it. We only communicated that the Python interface is deprecated, not the C one (even if this should not be used). cc @vstinner @encukou.
(I'm however in favor of doing it, just that I don't know if we can do it without an explicit notice)
sergey-miryanov commentedon May 11, 2025
set_typeset proto for pointer type, that used in lot of places. Also, it will break external users likepygletwho implementsIUnknowninterface with_type_.vstinner commentedon May 11, 2025
I don't think that the ctypes C API is considered as part of the public C API. I'm not sure if it's technically usable outside CPython.
encukou commentedon May 12, 2025
Yes, we'll need to deprecate
set_type, and its C implementation, separately; in 3.15.Now that
__pointer_type__is in, it should be possible to replaceset_typeby the new API, in all use cases we're aware of. But let's give users time to report other use cases.gh-133866: remove deprecated and undocumented function `ctypes.SetPoi…
pythongh-133866: remove deprecated and undocumented function `ctypes.…
pythongh-133866: remove deprecated and undocumented function `ctypes.…
ngoldbaum commentedon Mar 6, 2026
FWIW, I think the CFFI TSan CI hit a race caused by something related to this issue:
https://github.com/python-cffi/cffi/actions/runs/22596398074/job/65467405565?pr=232#step:5:365
Details
I'm trying to reduce this a little bit. I'm not sure if it only triggers on 3.14 or if it's possible on 3.15 as well. The CFFI CI was using free-threaded 3.14.3.
pythongh-133866: remove deprecated and undocumented function `ctypes.…
ZeroIntensity commentedon Jul 17, 2026
All done here?
sergey-miryanov commentedon Jul 17, 2026
set_typewasn't deprecated.ZeroIntensity commentedon Jul 17, 2026
Is that related to this issue? This issue seems to be about
SetPointerType, notset_type.sergey-miryanov commentedon Jul 18, 2026
SetPointerTypewas implemented usingset_type, and we discussed above that it would be good to deprecateset_type. But you're right that it's a different matter.I think this can be closed.
vstinner commentedon Jul 18, 2026
@encukou: What do you think of deprecating the
_ctypes.PyCPointerType.set_type()method? TheSetPointerType()function just called the method:encukou commentedon Jul 19, 2026
It makes sense, for the thread safety reasons. I left the issue open for that (my workflow would be to close this after opening the new one).
But I'm deferring to @ZeroIntensity now :)
ZeroIntensity commentedon Jul 21, 2026
What thread safety issues come with
set_type? Looking at the implementation, nothing jumps out at me as super wrong.encukou commentedon Jul 22, 2026
AFAIK it's this line in
PyCPointerType_SetProto:Other code borrows
stginfo->proto, assuming that it's set only once for a given object.We could add a lock around this, but since
set_typeis unneeded*, undocumented, and as far as I can see essentially unused, it's probably better to get rid ofset_type& stick to single assignment forstginfo->proto.* for background on the use case: the need for
SetPointerType/set_type-- "filling in" a pointer's type after creation -- is mentioned in ctypes 0.6.3+ docs (and earlier with a note that it “doesn't seem to work completely”). In 0.9.9.6 -- just before mergingctypesto stdlib -- the tutorial was updated: this use case is served by struct/union_fields_being “lazy“.ZeroIntensity commentedon Jul 23, 2026
Deprecating seems reasonable to me then, as long as there's a clear migration path.