Unexpected Behavior w/ prefix #736
Closed
Comments
matthewwithanm
added a commit
to matthewwithanm/fabric
that referenced
this issue
Sep 26, 2012
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.
matthewwithanm
added a commit
to matthewwithanm/fabric
that referenced
this issue
Sep 26, 2012
Just to clarify, this bug doesn't just affect |
Rolling this guy into #738 -- thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: