Incorrect behavior on bpython -i module.py and bpython module.py #506

Activity

1. RichardBronosky commented on Mar 11, 2015

   

   RichardBronosky

   on Mar 11, 2015

   More actions

   This is what I've found out so far:
   

   bpython/bpython/cli.py

   Line 1907 in 8aa4ddf

   bpython.args.exec_code(interpreter, args)

   calls https://github.com/bpython/bpython/blob/master/bpython/args.py#L118 which bubbles up to

   bpython/bpython/repl.py

   Line 112 in 7eaef53

   return code.InteractiveInterpreter.runsource(self, source,

   then https://github.com/python-git/python/blob/master/Lib/code.py#L87 then https://github.com/python-git/python/blob/master/Lib/code.py#L103

   I noticed that the last line there looks just like http://code.activestate.com/recipes/82234-importing-a-dynamically-generated-module/ which has me wondering... Can we use imp to create a new module and set its __dict__ equal to that code.InteractiveInterpreter instance's locals var. Then set sys.modules['__console__'] to that new module.

   That would at least provide access to the module that was executed via cli arg. This would still require special casing for any code that expected to find the module at sys.modules['__main__'] but it would work for sys.modules[__name__]
2. thomasballinger commented on Mar 13, 2015

   

   thomasballinger

   on Mar 13, 2015

   MemberAuthor

   More actions

   I like this approach, you're thinking something like this right? I wonder what the repercussions of swapping out __main__ would be.

   (bpython)tom-mba:bpython tomb$ git diff bpython/args.py
   diff --git a/bpython/args.py b/bpython/args.py
   index 6fd2b51..91c8fc7 100644
   --- a/bpython/args.py
   +++ b/bpython/args.py
   @@ -3,9 +3,10 @@ Module to handle command line argument parsing, for all front-ends.
    """
   
    from __future__ import print_function
   +import code
   +import imp
    import os
    import sys
   -import code
    from optparse import OptionParser, OptionGroup
   
    from bpython import __version__
   @@ -114,6 +115,9 @@ def exec_code(interpreter, args):
            source = sourcefile.read()
        old_argv, sys.argv = sys.argv, args
        sys.path.insert(0, os.path.abspath(os.path.dirname(args[0])))
   +    mod = imp.new_module('__console__')
   +    sys.modules['__console__'] = mod
   +    interpreter.locals = mod.__dict__
        interpreter.locals['__file__'] = args[0]
        interpreter.runsource(source, args[0], 'exec')
        sys.argv = old_argv
3. thomasballinger

   added

   bug

   bitesize

   on Mar 14, 2015
4. RichardBronosky commented on Mar 17, 2015

   

   RichardBronosky

   on Mar 17, 2015

   More actions

   Wow! That's a very literal translation of what I described. I didn't try it because I couldn't figure out where to put the change. Does it actually work? Thanks for doing that for me. Sorry for not submitting a patch myself.
5. thekthuser

   added a commit that references this issue on Apr 26, 2015

   fixed bug bpython#506

   a33048d
6. thomasballinger commented on Apr 27, 2015

   

   thomasballinger

   on Apr 27, 2015

   MemberAuthor

   More actions

   I'm going to try this for a day of using -i a lot.
7. thomasballinger

   closed this as completedon Apr 30, 2015
8. thomasballinger commented on Dec 6, 2015

   

   thomasballinger

   on Dec 6, 2015

   MemberAuthor

   More actions

   @RichardBronosky, I was writing up the changelog I can't recall what this fixed, and https://bpaste.net/show/5ae7b297bffe has expired. Do you recall what behavior this was fixing? Everything I could think of seems broken once again.
9. RichardBronosky commented on Dec 9, 2015

   

   RichardBronosky

   on Dec 9, 2015

   More actions

   I really don't recall. I guess I've learned my lesson about using anything other than gists for documentation.
10. thomasballinger commented on Dec 9, 2015

    

    thomasballinger

    on Dec 9, 2015

    MemberAuthor

    More actions

    Same here. I looks like it was to do with sys.modules[__name__] being the proper value, which has been fixed in master bpython -- I'm going to say that's what it was: what you fixed was now the namespace of the current module can be found at sys.modules[__name__].
11. thomasballinger

    added a commit that references this issue on Dec 10, 2015

    add #506 to changelog

    2a9b51f