This is take 2 after 924a808c (golang: Fix @func(cls) def name not to override name in calling context). There we fixed it not to override name if name was already set, but for the case of unset name it was still set. The following example was thus not working correctly as builtin next was overridden:

class BitSync

@func(BitSync)
def next(): ...         # this was shadowing access to builtin next

def peek(seq):
    return next(...)    # here next was taken not from builtin, but
                        # from result of above shadowing

To solve the problem in the patch from 2019 I initially contemplated patching bytecode because python unconditionally does STORE_NAME after a function is defined with decorator:

In [2]: c = """
   ...: @fff
   ...: def ccc():
   ...:     return 1
   ...: """

In [3]: cc = compile(c, "file", "exec")

In [4]: dis(cc)
  2           0 LOAD_NAME                0 (fff)
              3 LOAD_CONST               0 (<code object ccc at 0x7fafe58d0130, file "file", line 2>)
              6 MAKE_FUNCTION            0
              9 CALL_FUNCTION            1
             12 STORE_NAME               1 (ccc)	<-- NOTE means: ccc = what fff() call returns
             15 LOAD_CONST               1 (None)
             18 RETURN_VALUE

However after hitting this problem for real again and taking a fresh look I found a way to arrange for the good end result without bytecode magic: if name is initially unset @func can install its own custom object, which, when overwritten by normal python codeflow of invoking STORE_NAME after decorator, unsets the attribute.

That works quite ok and the patch with the fix is small.

/cc @jerome