This is what I've found out so far:

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__]

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

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.

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

@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.

I really don't recall. I guess I've learned my lesson about using anything other than gists for documentation.

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__].