`@overload` decorator on compiled functions is not tested

[sobolevn]

If I change this line

cpython/Lib/typing.py

Line 2584 in a91f255

pass

to be

 try:
 _overload_registry[f.__module__][f.__qualname__][f.__code__.co_firstlineno] = func
 except AttributeError:
 # Not a normal function; ignore.
 raise # pass

test_typing continues to pass as expected. I think it is dangerous, because we can accidentally break something and not notice.

I will send a simple test case to catch this: we should not fail.

[sobolevn]

Moreover, this has a side-effect:

overload(sum)

creates a following entry in _overload_registry:

defaultdict(<function OverloadTests.<lambda> at 0x10185cec0>,{'builtins': defaultdict(<class 'dict'>,{'print':{}})})

[sobolevn]

This happens because only the last [f.__code__.co_firstlineno] = func part of

 try:
 _overload_registry[f.__module__][f.__qualname__][f.__code__.co_firstlineno] = func
 except AttributeError:
 # Not a normal function; ignore.
 pass

fails with AttrtibuteError. Others are keys are recorded already by a defaultdict. I don't think it is a big deal, but it is surely interesting.

[AlexWaygood]

The current code for overload() is:

f = getattr(func, "__func__", func)
try:
 _overload_registry[f.__module__][f.__qualname__][f.__code__.co_firstlineno] = func
except AttributeError:
 # Not a normal function; ignore.
 pass
return _overload_dummy

If we wanted to get rid of the side effect, we could maybe change the code to something like this:

f = getattr(func, "__func__", func)
try:
 mod, qualname, lineno = f.__module__, f.__qualname__, f.__code__.co_firstlineno
except AttributeError:
 # Not a normal function; ignore.
 pass
else:
 _overload_registry[mod][qualname][lineno] = func
return _overload_dummy

But we worked quite hard to make sure that the performance regression introduced by making overloads retrievable at runtime was as small as possible. So I'd want to make sure that this didn't make things any slower.

[sobolevn]

I don't think that we want to remove this side-effect. get_overloads still works correctly for end users 🤔

Moreover, annotating C functions is not that common. It is more like an exceptional case.
Slowing down regular use-cases is not worth it in my opinion.

[AlexWaygood]

I don't think that we want to remove this side-effect. get_overloads still works correctly for end users 🤔

Moreover, annotating C functions is not that common. It is more like an exceptional case. Slowing down regular use-cases is not worth it in my opinion.

Yeah, the possibility of this side effect causing a memory leak is pretty minimal :)