Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LoggingContext decorator isn't typechecked, which means functions it decorates become untypechecked #60

Open
Quidge opened this issue Jan 4, 2023 · 0 comments · May be fixed by #79
Open

LoggingContext decorator isn't typechecked, which means functions it decorates become untypechecked #60

Quidge opened this issue Jan 4, 2023 · 0 comments · May be fixed by #79

Comments

@Quidge
Copy link

Quidge commented Jan 4, 2023 •
edited
Loading

If you want to use the LoggingContext in the decorator style, you lose the typechecking of the decorated function.

@LoggingContext("thing_fn")
def thing() -> SomeType:
	...

I can get that back by instead doing the context manager approach as the first thing that happens in the function, but that defeats the point of having the decorator:

def thing() -> SomeType:
	with LoggingContext("thing_fn"):
		...

Mypy has a page on how to set this up: https://mypy.readthedocs.io/en/stable/generics.html#declaring-decorators
sapslaj added a commit to sapslaj/woodchipper that referenced this issue Nov 16, 2023
@sapslaj
Add type information to LoggingContext.__call__
6831f54 
Adds a `DecoratedCallable` TypeVar and uses that in the type hints for the
`__call__` method in `LoggingContext`. This allows type information to pass
through correctly when used as a decorator.

It seems like the `@wraps` decorator on the wrapper mangles the type info so I
had to disable type checking on the return because Pyright was convinced it was
wasn't the correct type, but the tests proved otherwise.

I'm not sure there's a good way to test since at runtime the function signature
is getting passed through correctly. It's only on the type checking pass that
things break down. It's probably fine as-is since no tests broke as a result,
but figured it was worth mentioning.

Fixes tackle-io#60
@sapslaj sapslaj linked a pull request Nov 16, 2023 that will close this issue
Open
sapslaj added a commit to sapslaj/woodchipper that referenced this issue Feb 6, 2024
@sapslaj
Add type information to LoggingContext.__call__
b8d9ed1 
Adds a `DecoratedCallable` TypeVar and uses that in the type hints for the
`__call__` method in `LoggingContext`. This allows type information to pass
through correctly when used as a decorator.

It seems like the `@wraps` decorator on the wrapper mangles the type info so I
had to disable type checking on the return because Pyright was convinced it was
wasn't the correct type, but the tests proved otherwise.

I'm not sure there's a good way to test since at runtime the function signature
is getting passed through correctly. It's only on the type checking pass that
things break down. It's probably fine as-is since no tests broke as a result,
but figured it was worth mentioning.

Fixes tackle-io#60
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add type information to LoggingContext.__call__ sapslaj/woodchipper
1 participant
@Quidge