[issue45100] Improve help() by making typing.overload() information accessible at runtime

Guido van Rossum added the comment: Looks like there may be a new plan where we solve a smaller problem (overloads) in the context of typing only. -- ___ Python tracker ___ _

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Change by Jelle Zijlstra : -- keywords: +patch pull_requests: +29832 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31716 ___ Python tracker ___ _

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Alex Waygood added the comment: The latest plan sounds good to me. I have some Thoughts on the proposed API, but it will be easier to express those as part of a PR review. Looking forward to seeing the PR! -- ___ Python tracker

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Jelle Zijlstra added the comment: We could make my proposed overload registry more reusable by putting it in a different module, probably functools. (Another candidate is inspect, but inspect.py imports functools.py, so that would make it difficult to use the registry for functools.singledis

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Alex Waygood added the comment: I'd dearly like better introspection tools for functions decorated with @overload, but I'd rather have a solution where: - inspect.signature doesn't have to import typing. That doesn't feel worth it for users who aren't using typing.overload, but inspect.signa

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Change by Alex Waygood : -- nosy: +sobolevn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Spencer Brown added the comment: Had a potential thought. Since the only situation we care about is overload being used on function definitions in lexical order, valid calls are only that on definitions with ascending co_firstlineno counts. Expanding on Jelle's solution, the overload() decor

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Jelle Zijlstra added the comment: I'm OK with not fully supporting overloads created in nested functions; that's a pretty marginal use case. But it's true that my proposed implementation would create a memory leak if someone does do that. I don't immediately see a way to fix that with weakre

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Spencer Brown added the comment: I'm not sure a get_overloads() function potentially called after the fact would fully work - there's the tricky case of nested functions, where the overload list would need to be somehow cleared to ensure every instantiation doesn't endlessly append to the sa

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Guido van Rossum added the comment: Sounds good to me. (I don’t care what happens at runtime but I want to support the folks who do.)-- --Guido (mobile) -- ___ Python tracker _

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Jelle Zijlstra added the comment: I made a similar suggestion in issue46821 (thanks Alex for pointing me to this older issue): Currently, the implementation of @overload (https://github.com/python/cpython/blob/59585d6b2ea50d7bc3a9b336da5bde61367f527c/Lib/typing.py#L2211) simply returns a du

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Raymond Hettinger added the comment: Note, I'm not proposing a create_function() decorator. That is just for the proof of concept. The actual logic would go into normal function creation, the same place that __annotations__ gets added. Also, there may be a better place than func.__globals_

[issue45100] Improve help() by making typing.overload() information accessible at runtime

Change by Raymond Hettinger : -- title: Teach help about typing.overload() -> Improve help() by making typing.overload() information accessible at runtime versions: +Python 3.11 ___ Python tracker __