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.

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

make contextmanager return AbstractContextManager #6521

Closed
wants to merge 1 commit into from

Conversation

JelleZijlstra
Copy link
Member

Fixes #6520.

There might be a good reason to keep the current implementation, but I want to see what CI says. I believe mypy has a plugin for @contextmanager, so it may not show that much.

I found no motivation for the separate class in https://github.com/python/typeshed/pulls?q=is%3Aissue+GeneratorContextManager+.

Fixes #6520.

There might be a good reason to keep the current implementation, but I want to see what CI says. I believe mypy has a plugin for `@contextmanager`, so it may not show that much.

I found no motivation for the separate class in https://github.com/python/typeshed/pulls?q=is%3Aissue+GeneratorContextManager+.
@github-actions
Copy link
Contributor

github-actions bot commented Dec 6, 2021

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@@ -36,7 +36,7 @@ class _GeneratorContextManager(AbstractContextManager[_T_co]):
def __call__(self, func: _F) -> _F: ...

# type ignore to deal with incomplete ParamSpec support in mypy
def contextmanager(func: Callable[_P, Iterator[_T]]) -> Callable[_P, _GeneratorContextManager[_T]]: ... # type: ignore[misc]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_GeneratorContextManager is also used in stubs/decorator/decorator.pyi.

  • Should we change decorator.pyi too?
  • If we change both, should we delete _GeneratorContextManager?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know about decorator; if it uses the class we can keep it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently decorator's documentation explains what the __call__ method is supposed to do: https://github.com/micheles/decorator/blob/master/docs/documentation.md#contextmanager

Maybe we should just keep it, because it is a documented feature.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another observation: the implementation of decorator just does from contextlib import _GeneratorContextManager, and uses it as a base class. So their solution to #6520 (or rather, a similar problem at runtime) is to just import it and not worry about it.

@JelleZijlstra
Copy link
Member Author

The separate class supports a documented behavior of @contextmanager where you can use the decorated function as a decorator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should the return type of decorated contextlib.contextmanager be AbstractContextManager?
2 participants