this fix is not complete; python3 evaluates __name__ == '__main__' in __main__.py to True; bpython does not.

i think you want to be using runpy.run_path if possible. i imagine this will give you correct behavior for things like running bytecode, zipped module dirs, etc.

here is a sample stack trace from python3 execution, indicating that runpy is used:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "boot/__main__.py", line 30, in <module>
    raise Exception()
Exception

Thanks for the hint. I'll look into it.

Unfortunately it's not an option until we decide to drop support for 2.6.

It also requires major changes to the current main implementations of the frontends. Maybe we could execute with runpy and then inject the globals into our own interpreter.

After some testing I don't think that it's possible to use runpy. It breaks -i.

I thought about using runpy in #284 but ran into the same thing.

meaning that this would be a very intrusive change? python has its own -i option, so i wonder if reading that implementation works would be helpful. i imagine it could be a large undertaking, but the obvious benefit is that you will get the 'official' behavior now and in the future. @thomasballinger i'd be down to pair on looking at how this works in cpython sometime if you are interested.