@overload decorator on compiled functions is not tested

If I change this line

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.

pythongh-96478: Test `@overload` on C functions

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': {}})})

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.

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.

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.

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 :)

gh-96478: Test `@overload` on C functions (#96479)

pythongh-96478: Test `@overload` on C functions (pythonGH-96479)

Backport python/cpython#96479

Backport python/cpython#96479 (#73)

pythongh-96478: Fix new test when run in refleak mode

gh-96478: Fix new test when run in refleak mode (#96615)

gh-96478: Test `@overload` on C functions (GH-96479)

pythongh-96478: Fix new test when run in refleak mode (pythonGH-96615)

gh-96478: Fix new test when run in refleak mode (GH-96615)

Fixed by #96479

Navigation Menu

Repository navigation

`@overload` decorator on compiled functions is not tested #96478

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

@overload decorator on compiled functions is not tested #96478

Description

Activity

sobolevn commented on Sep 1, 2022

sobolevn commented on Sep 1, 2022

AlexWaygood commented on Sep 1, 2022

sobolevn commented on Sep 1, 2022

AlexWaygood commented on Sep 1, 2022

kumaraditya303 commented on Sep 30, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`@overload` decorator on compiled functions is not tested #96478