3.12.0b4 Backwards incompatible change with reassignment of cls.__new__ and super()

@carljm

Bug report

Noticed this while testing 3.12.0b4. While in my particular case I can work around it, it never the less is a change in behavior to 3.11.

class FixedIntType(int):
    _signed: bool

    def __new__(cls, *args, **kwargs):
        print(f"{cls}, {args=}")
        return super().__new__(cls, *args, **kwargs)

    def __init_subclass__(cls, signed: int | None = None) -> None:
        super().__init_subclass__()
        if signed is not None:
            cls._signed = signed

        if "__new__" not in cls.__dict__:
            cls.__new__ = cls.__new__  # <-- This line triggers the error

class uint_t(FixedIntType, signed=False):
    pass

class CustomInt(uint_t):
    def __new__(cls, value: int = 0):
        return super().__new__(cls, value)

    def with_id(self, value: int):
        return type(self)(value)

CustomInt().with_id(1024)

<class '__main__.CustomInt'>, args=(0,)
<class '__main__.CustomInt'>, args=(<class '__main__.CustomInt'>, 1024)
Traceback (most recent call last):
  File "/.../cpython/test.py", line 26, in <module>
    CustomInt().with_id(1024)
  File "/.../cpython/test.py", line 24, in with_id
    return type(self)(value)
           ^^^^^^^^^^^^^^^^^
  File "/.../cpython/test.py", line 21, in __new__
    return super().__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/.../cpython/test.py", line 6, in __new__
    return super().__new__(cls, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: int() base must be >= 2 and <= 36, or 0

Without cls.__new__ = cls.__new__

<class '__main__.CustomInt'>, args=(0,)
<class '__main__.CustomInt'>, args=(1024,)

I bisected the issue to #103497.
/CC: @carljm

Your environment

CPython versions tested on: 3.120b4
Operating system and architecture: macOS ARM64

Linked PRs

Thanks for this report!

__new__ is automagically treated as a staticmethod (but only when it's part of the type at construction, not if it's assigned afterward.) So the repro case ultimately simplifies and de-sugars to this:

class A:
    @staticmethod
    def some(cls, *args, **kwargs):
        print(f"{cls}, {args=}")
        assert not args
        assert not kwargs

class B(A):
    def some(cls, *args, **kwargs):
        return super().some(cls, *args, **kwargs)

class C(B):
    @staticmethod
    def some(cls):
        return super().some(cls)

C.some(C)
C.some(C)

Note that B.some is not a @staticmethod, while A.some and C.some both are. This is equivalent to what happens in the OP. The assignment cls.__new__ = cls.__new__ looks up the staticmethod in the right hand side (from the base class via MRO lookup, since it doesn't exist yet on cls) and "unwraps" the staticmethod in descriptor resolution, returning a plain function object, and then assigns that plain function object (not a staticmethod) as the __new__ method on the new subclass. (And dynamic assignment of __new__ does not magically wrap it in staticmethod.) So the middle class in the hierarchy (uint_t in the OP) ends up with a non-staticmethod __new__, while the top and bottom classes have a normal staticmethod __new__.

This simplified and de-sugared repro works in 3.11, but fails in a similar way to the OP in main and 3.12:

➜ ../dbg/python superbug3.py
<class '__main__.C'>, args=()
<class '__main__.C'>, args=(<class '__main__.C'>,)
Traceback (most recent call last):
  File "/home/carljm/cpython-builds/repros/superbug3.py", line 18, in <module>
    C.some(C)
  File "/home/carljm/cpython-builds/repros/superbug3.py", line 15, in some
    return super().some(cls)
           ^^^^^^^^^^^^^^^^^
  File "/home/carljm/cpython-builds/repros/superbug3.py", line 10, in some
    return super().some(cls, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/carljm/cpython-builds/repros/superbug3.py", line 5, in some
    assert not args
AssertionError

The double call to C.some(C) in the repro is necessary so that we specialize LOAD_SUPER_ATTR to LOAD_SUPER_ATTR_METHOD, triggering the bug. The base LOAD_SUPER_ATTR goes through the same code path as an unoptimized LOAD_ATTR; CALL.

What we have in these examples is a "class-mode" super() call (e.g. super(MyClass, MyClass).foo(...), where the second super arg is also a class, not an instance). (Zero-arg super() implicitly uses the first argument of the method as the second arg to super(), and in this case that first arg of the method is a class, not an instance.)

In a class-mode super() call (just like for a normal lookup directly on a class), we do not pass an instance to the descriptor-getter, only a type (e.g. func_descr_get(descr, NULL, type) instead of func_descr_get(descr, obj, type). In the case of a regular function object, this causes the function descriptor to just return the function itself (no bound method), which is the same behavior the staticmethod descriptor always has! So as long as we are only doing class lookups, staticmethod has no effect, and therefore we can get away with this mixed staticmethod/non-staticmethod hierarchy just fine.

The bug here is that the LOAD_SUPER_ATTR_METHOD specialization tries to use the LOAD_METHOD optimization (avoid actually creating a bound method object via descriptor, and instead just detect that case and ensure the extra argument is provided), but fails to account for the fact that a class lookup of a regular function object (not a classmethod) is just a function call, not a method call.

Fix coming shortly.

pythongh-106917: don't wrongly optimize super 'method' loads off types

pythongh-106917: fix super classmethod calls to non-classmethods

gh-106917: fix super classmethod calls to non-classmethods (#106977)

[3.12] pythongh-106917: fix super classmethod calls to non-classmetho…

[3.12] gh-106917: fix super classmethod calls to non-classmethods (GH…

pythongh-106917: fix super classmethod calls to non-classmethods (pyt…

Navigation Menu

Repository navigation

3.12.0b4 Backwards incompatible change with reassignment of `cls.new` and `super()` #106917

Bug report

Your environment

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

3.12.0b4 Backwards incompatible change with reassignment of cls.__new__ and super() #106917

Description

Bug report

Your environment

Linked PRs

Activity

carljm commented on Jul 21, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

3.12.0b4 Backwards incompatible change with reassignment of `cls.new` and `super()` #106917