`super()` raises `TypeError` in a `ctypes.util.struct` method

[fedonman]

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

Linked PRs

• gh-158418: Fix zero-argument super() in ctypes.util.struct methods #158419

[ZeroIntensity]

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() with ctypes.Structure subclasses? It might be okay to just document that this doesn't work.

[johnslavik]

Do we have any data on how often people use super() with ctypes.Structure subclasses?

+1 on the question. With NamedTuple it 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]

Well received.

…

On Wed, Sep 30, 2026 at 9:05 AM Bartosz Sławecki ***@***.***> wrote: *johnslavik* left a comment (python/cpython#158418) <#158418 (comment)> Why is this supposed to work? @structclass Point: x: c_int y: c_int def __init__(self, x=0, y=0): super().__init__(x, y) I'm finding super().__init__(x, y) incorrect here. — Reply to this email directly, view it on GitHub <#158418?email_source=notifications&email_token=CI4YCMDH3PNNGEN2PS4TKRD5RS5GPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJQGY4TCNZVHE42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5906917599>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CI4YCMCWBV5T767IHB3SKWT5RS5GPAVCNFSNUABEKJSXA33TNF2G64TZHM4DCNJZHA4TMMJ3JFZXG5LFHM2TMMZSGYZTSMBTGGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CI4YCMDAOU67SQTAUFHM4535RS5GPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJQGY4TCNZVHE42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CI4YCMCU6Q4CHJIYGCCZEW35RS5GPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJQGY4TCNZVHE42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sergey-miryanov]

Reported to GH

[fedonman]

I agree that importing a private helper from dataclasses isn't ideal. We don't have usage data for @struct yet, since it hasn't been released. I was thinking of a custom __init__ that calls Structure.__init__, which already works with either super(Point, self).__init__(...) or Structure.__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 struct entry and showing the two-argument super() workaround. I can update the PR to do that if you're happy with this approach.

[ZeroIntensity]

I did find a number of examples of people using super() in ctypes.Structure subclasses:

1. hite4044/WinEnchantKit
2. qilingframework/qiling
3. ionite34/einspect
4. shawwn/libtpu-python
5. Spexophis/minimiao
6. linfeiliu/PyDA30L
7. NUAACTF2022-Challenges
8. Spexophis/Microscope_GUI

They all seem to be from people instinctively calling super().__init__() with subclasses. I'm not worried about that with the @struct decorator because the inheritance is hidden, so people won't be inclined to call super().__init__(), so I'm okay with just documenting that no-arg super() doesn't work with @struct.

[johnslavik]

They all seem to be from people instinctively calling super().__init__() with subclasses. I'm not worried about that with the @struct decorator because the inheritance is hidden, so people won't be inclined to call super().__init__(), so I'm okay with just documenting that no-arg super() doesn't work with @struct.

+1 (despite the docs warranting a base)