You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
The prefix context manager (and probably others that are using _setenv) don't behave as expected when not called immediately prior to __enter__(). This means that the context manager isn't usable with contextlib.nested. Here's an example:
The reason is because the new values are being stored at the time prefix is called—not when the context is entered. So, in the example above, when prefix is called the first time, it defines the context manager as setting command_prefixes to the current value ([]) plus ['echo 1']. When it's called the second time, the current value of command_prefixes is still an empty list (because the first context hasn't been entered yet), so the context manager is defined as setting command_prefixes to ['echo 2']. Therefore, entering the second context manager clobbers any effect of entering the first.
The fix, I think, is to defer the getting of command_prefixes until the context is entered.
The text was updated successfully, but these errors were encountered:
This test initializes two prefix context managers before using them.
Since the context is not entered immediately after initialization, the
test will fail if the bug is present.
Just to clarify, this bug doesn't just affect nested, but any situation in which the context managers aren't entered immediately after initialization. The test in 65647c6 contains a simple nested-less example.
The
prefix
context manager (and probably others that are using_setenv
) don't behave as expected when not called immediately prior to__enter__()
. This means that the context manager isn't usable withcontextlib.nested
. Here's an example:Expected Output:
Actual Output:
The reason is because the new values are being stored at the time
prefix
is called—not when the context is entered. So, in the example above, whenprefix
is called the first time, it defines the context manager as settingcommand_prefixes
to the current value ([]
) plus['echo 1']
. When it's called the second time, the current value ofcommand_prefixes
is still an empty list (because the first context hasn't been entered yet), so the context manager is defined as settingcommand_prefixes
to['echo 2']
. Therefore, entering the second context manager clobbers any effect of entering the first.The fix, I think, is to defer the getting of
command_prefixes
until the context is entered.The text was updated successfully, but these errors were encountered: