Repository navigation
super() raises TypeError in a ctypes.util.struct method #158418
Description
Bug description:
Zero-argument super() raises TypeError in a method of a class decorated with ctypes.util.struct:
from ctypes import c_int
from ctypes.util import struct
@struct
class Point:
x: c_int
y: c_int
def __init__(self, x=0, y=0):
super().__init__(x, y)
print(Point(1, 2).x)TypeError: super(type, obj): obj (instance of Point) is not an instance or subtype of type (Point).
The same method on a plain Structure subclass works. __class__ in such a method also refers to the original class instead of the one the decorator returns.
Expected: super() and __class__ refer to the class returned by @struct, and the example prints 1.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Activity
ZeroIntensity commentedon Sep 30, 2026
Agreed that we should probably deal with this in one way or another, but the attached PR adds a lot of extra complexity. Do we have any data on how often people use
super()withctypes.Structuresubclasses? It might be okay to just document that this doesn't work.johnslavik commentedon Sep 30, 2026
+1 on the question. With
NamedTupleit simply didn't make sense to fix it.The tests provided in the PR do not exercise inheritance at all. Do we really need
super()to work in those classes? (And if we decide we don't, I'm all for improving the error message)dqqFA8995 commentedon Sep 30, 2026
sergey-miryanov commentedon Sep 30, 2026
fedonman commentedon Sep 30, 2026
I agree that importing a private helper from
dataclassesisn't ideal. We don't have usage data for@structyet, since it hasn't been released. I was thinking of a custom__init__that callsStructure.__init__, which already works with eithersuper(Point, self).__init__(...)orStructure.__init__(self, ...). Subclasses of the decorated class aren't affected either.Unlike
NamedTuple, the decorator runs after__classcell__has been consumed. To raise a useful error, we'd have to check each method's__code__.co_freevars, including methods wrapped in classmethods and properties. That's much of the same traversal the PR already does.I'd suggest documenting the limitation in the
structentry and showing the two-argumentsuper()workaround. I can update the PR to do that if you're happy with this approach.ZeroIntensity commentedon Sep 30, 2026
I did find a number of examples of people using
super()inctypes.Structuresubclasses:They all seem to be from people instinctively calling
super().__init__()with subclasses. I'm not worried about that with the@structdecorator because the inheritance is hidden, so people won't be inclined to callsuper().__init__(), so I'm okay with just documenting that no-argsuper()doesn't work with@struct.johnslavik commentedon Oct 1, 2026
+1 (despite the docs warranting a base)
gh-158418: Document that zero-arg `super` doesn't work with `ctypes.u…