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
embed(): Default to the future compiler flags of the calling frame. #2096
Conversation
Kudos for getting onto this so quickly. That looks like exactly the approach I was thinking of. Can we have a test for this - even if it's not possible to do as a fully automated test, we should have a script in |
Aha! I didn't know of the existence of |
Aha! I didn't know of the existence of |
Checked the script in 2.7 and 3.2. Looks OK to me, but I'll let someone else give it a once over. |
@bfroehle Thanks a lot for this! |
# Roughtly equal to PyCF_MASK | PyCF_MASK_OBSOLETE as defined in pythonrun.h, | ||
# this is used as a bitmask to extract future-related code flags. | ||
PyCF_MASK = functools.reduce(operator.or_, | ||
(f.compiler_flag for f in codeop._features)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we not rely on codeop._features
and instead produce this as:
PyCF_MASK = functools.reduce(operator.or_,
(getattr(__future__, fname).compiler_flag
for fname in __future__.all_feature_names))
For reference, codeop._features
is implemented as
# codeop.py:
import __future__
_features = [getattr(__future__, fname)
for fname in __future__.all_feature_names]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd side with the version using __future__
, because codeop._features
is undocumented, so it could theoretically be removed or renamed in a future version of Python.
Made the changes, rebased, and squashed into two commits (feature, tests). I ended up naming the option |
I think this is ready to go. |
I don't think it's currently possible to pass Also, |
Wow that was bad of me. I never tested passing Okay added documentation and now treat |
OK, that's looking good now. Assuming you've run the test scripts to check that it's all working as it should, I think you can merge when you're ready. |
embed(): Default to the compile flags of the calling frame. This means that if a script contains: from __future__ import division from IPython import embed embed() ... then the embedded IPython session will also use the future division, i.e., 1/2 evaluates to 0.5. In addition, the user can pass the keyword argument `compile_flags` to embed to override the default inheritance behavior, e.g., embed(compile_flags=__future__.print_function.compiler_flag) Multiple compile flags can be combined with the bitwise or operator.
With certain sets of arguments `compile_flags` might be left as `None`. This caused IPython to internally raise a TypeError when it tried to do a bitwise or between `shell.compile.flags` and `PyCF_ONLY_AST` in `CachingCompiler.ast_parse`. The regression was introduced in: b70ac12 embed(): Default to the future compile flags of the calling frame.
Fix regression in embed() from pull-request #2096.
With certain sets of arguments `compile_flags` might be left as `None`. This caused IPython to internally raise a TypeError when it tried to do a bitwise or between `shell.compile.flags` and `PyCF_ONLY_AST` in `CachingCompiler.ast_parse`. The regression was introduced in: b70ac12 embed(): Default to the future compile flags of the calling frame.
embed(): Default to the compile flags of the calling frame. This means that if a script contains: from __future__ import division from IPython import embed embed() ... then the embedded IPython session will also use the future division, i.e., 1/2 evaluates to 0.5. In addition, the user can pass the keyword argument `compile_flags` to embed to override the default inheritance behavior, e.g., embed(compile_flags=__future__.print_function.compiler_flag) Multiple compile flags can be combined with the bitwise or operator.
With certain sets of arguments `compile_flags` might be left as `None`. This caused IPython to internally raise a TypeError when it tried to do a bitwise or between `shell.compile.flags` and `PyCF_ONLY_AST` in `CachingCompiler.ast_parse`. The regression was introduced in: b70ac12 embed(): Default to the future compile flags of the calling frame.
Fix regression in embed() from pull-request ipython#2096.
As discussed on the mailing list by Joon Ro:
The attached pull request changes the behavior of embed to, by default, use the future compiler flags from the calling frame.