The evil plan is to remove custom Struct.__init__() method and move all initialization logic to the Struct.__new__(). Something, that was done by #94532 before.

CC @meadori per experts index.

And what about the following case?

class MyStruct(struct.Struct):
    def __init__(self, arg):
        super().__init__('>h')

my_struct = MyStruct('<h')
my_struct.pack(12345)

There should emit a FutureWarning, because the current and the future code produce different results. MyStruct(5) should emit a DeprecationWarning, because it works in the current code, but will be error in future. ``MyStruct('>h')` should work without warnings.

@serhiy-storchaka, this seems too complex for me.

Look, we are going to that state: #94532. (I did a working patch to play with in skirpichev#17.) That means, eventually the Struct's __init__() will be no-op (and accept any arguments).

Thus, we should warn users on this pattern: explicit call of the __init__() on an object of some Struct subclass. Just in all above examples. Does make sense for you?

CC @vstinner

I tried to fix corner cases, but since all code and tests were rewritten, I created a separate PR #145580.

Ah, I forgot that format is positional or keyword argument. Will adapt code a bit.

Apparently, this overflowed my bandwidth. I'm happy to see the issue is in more qualified hands now.

The #145580 looks ok for me, but I worry that such approach is much more complex just to satisfy the constraint:

• It should be possible to write a user code compatible with future Python versions and with old Python versions which works without warnings during transitional period.

Transition could be handled with, say:

if sys.version_info < (3, 15):
    # old idiom:
    class MyStruct(struct.Struct):
        def __init__(self):
            super().__init__('>h')
else:
    # new idiom:
    class MyStruct2(struct.Struct):
        def __new__(cls):
            self = super().__new__(cls, '>h')
            return self

Thanks for reviews!