Make decorator-based context managers reentrant
Hi, I was wondering why decorator-based context managers are not reentrant or even reusable. They could be made reusable by initializing the generator in __enter__() instead of __init__(). They could be made reentrant by storing generatos in a stack. A similar thing has been implemented for redirect_stdout in 8e113b418df7d0c8480e1e2de29a385e1f31b15b. I understand that not all generator-based context managers can be reentrant by their nature. But currently it is impossible to make them reentrant, which IMHO is an unnecessary restriction. I could find very little discussion on this. Are there any strong reasons why it was implemented this way or should I create a pull request to change it? (My specific use case is a TUI application where I want to make sure that the terminal is restored to a usable state on exit, but also need to step in and out of the TUI on SIGTSTP/SIGCONT.) thanks, tobias https://docs.python.org/3/library/contextlib.html#single-use-reusable-and-re...
On 30 Mar 2023, at 08:10, Tobias Bengfort <tobias.bengfort@posteo.de> wrote:
Hi,
I was wondering why decorator-based context managers are not reentrant or even reusable.
Do you mean this use of reentrant? https://en.wikipedia.org/wiki/Reentrancy_(computing)
They could be made reusable by initializing the generator in __enter__() instead of __init__(). They could be made reentrant by storing generatos in a stack. A similar thing has been implemented for redirect_stdout in 8e113b418df7d0c8480e1e2de29a385e1f31b15b.
I understand that not all generator-based context managers can be reentrant by their nature. But currently it is impossible to make them reentrant, which IMHO is an unnecessary restriction.
I could find very little discussion on this. Are there any strong reasons why it was implemented this way or should I create a pull request to change it?
(My specific use case is a TUI application where I want to make sure that the terminal is restored to a usable state on exit, but also need to step in and out of the TUI on SIGTSTP/SIGCONT.)
thanks, tobias
https://docs.python.org/3/library/contextlib.html#single-use-reusable-and-re... _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K7M62J... Code of Conduct: http://python.org/psf/codeofconduct/
On 30/03/2023 09.21, Barry wrote:
On 30 Mar 2023, at 08:10, Tobias Bengfort <tobias.bengfort@posteo.de> wrote: I was wondering why decorator-based context managers are not reentrant or even reusable.
Do you mean this use of reentrant? https://en.wikipedia.org/wiki/Reentrancy_(computing)
I mean mean it as used in the docs: More sophisticated context managers may be “reentrant”. These context managers can not only be used in multiple with statements, but may also be used inside a with statement that is already using the same context manager.
participants (2)
-
Barry -
Tobias Bengfort