Terry J. Reedy added the comment:

I agree that this is broken.  I verified that the following works in 2.7.9

>>> from __future__ import division, print_function
>>> 32 / 5
6.4
>>> print(2,3,sep='**')
2**3

#13296 was about self.compile.compiler.flags (in ModifiedInterpreter, which 
inherits .compile... from code.InteractiveInterpreter) not being *reset* to 
their original values upon Shell restart.  They are now.

This issue is about the same flags not being *set* by Run Module.  This will be 
tricky to fix, but I think it can be done using the previous flag issue as a 
hint.

self.compile (in InteractiveInterpreter) = codeop.CommandCompiler().
The docstring for the class says
    """Instances of this class have __call__ methods identical in
    signature to compile_command; the difference is that if the
    instance compiles program text containing a __future__ statement,
    the instance 'remembers' and compiles all subsequent program texts
    with the statement in force."""
The __call__ method handles partial or complete single statements.

Run -> Run Module F5, on the other hand,  is handled by the ScriptBindind.py 
extension.  ScriptBinding.run_module_event calls .checksyntax().  The latter 
calls builtin compile(), independent of the shell interpreter.compile, without 
saving the compile flags.

To save the compile flags, we could use codeop.Compile.__call__, which calls 
builtin compile() and then extracts and saves future compile flags from the 
resulting code object using constants defined in the module.

The next issue is timing.  The shell restarts (and resets its flags) only after 
the file passes compile and tabnanny steps.  After the restart, it should be 
possible to update the shell compile flags with any future flags saved by the 
Compile() instance.

I have skipped over some details (including the lack of tests for Run Module), 
but I *think* that the above outlines a safe solution.  As for 3.x, there are 
changes in 3.4 ScriptBinding.py, but the essential points for this issue seem 
the same.  3.x should be patched also to be ready for future __future__ imports.

----------
nosy: +terry.reedy
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23069>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to