`classmethod` and `staticmethod` can crash with `NULL` / uninitialized callables

[colesbury]

Crash report

The following code crashes in a debug build:

f = classmethod.__new__(classmethod, None)
print(f)

Or equivalently:

class MyStaticMethod(staticmethod):
    def __init__(self, func):
        print(self)

print(MyStaticMethod(lambda x: x))

Objects/unicodeobject.c:3103: const char *unicode_fromformat_arg(_PyUnicodeWriter *, const char *, va_list *): Assertion `obj' failed.

The problem is that sm_callable/cm_callable fields are only initialized in the __init__ function and not all code (like the repr) handles the NULL case.

Additionally, even though __func__ isn't writable, you can modify it by calling __init__ on an already initialized staticmethod or classmethod.

Linked PRs

• gh-144330: Initialize staticmethod/classmethod callables in tp_new #144364
• gh-144330: Initialize staticmethod/classmethod callables in tp_new #144440
• gh-144330: Initialize classmethod and staticmethod in new #144469
• [3.14] gh-144330: Initialize classmethod and staticmethod in new #144498
• [3.13] gh-144330: Initialize classmethod and staticmethod in new (GH-144498) #144537

[colesbury]

For 3.15, it would be nice to move the initialization to a tp_new instead of tp_init and avoid all these problems

[Aniketsy]

I’d be happy to work on this, as suggested.

[skirpichev]

it would be nice to move the initialization to a tp_new instead of tp_init and avoid all these problems

I think we can't do this without prior deprecation, no? See #143715 for similar case.

[vstinner]

@colesbury:

For 3.15, it would be nice to move the initialization to a tp_new instead of tp_init and avoid all these problems

I wrote PR gh-144469 to implement this change.

[vstinner]

Oh, 3.13 and 3.14 are also affected, I reopen the issue.

I wrote a simpler fix for 3.13 and 3.14: #144498