GitLab

@vnmabus reports that gpython does not support running directories with
__main__.py inside:

    With normal python:

        >>> mkdir kk
        >>> echo "print('Hello')" > kk/__main__.py
        >>> python kk
        Hello

    With gpython:

        >>> mkdir kk
        >>> echo "print('Hello')" > kk/__main__.py
        >>> python kk
        Traceback (most recent call last):
          File "./software_release/bin/python", line 313, in <module>
            pymain(sys.argv)
          File ".../parts/pygolang/gpython/__init__.py", line 284, in pymain
            run(mmain)
          File ".../parts/pygolang/gpython/__init__.py", line 188, in run
            _execfile(filepath, mmain.__dict__)
          File ".../parts/pygolang/gpython/__init__.py", line 328, in _execfile
            with open(path, "rb") as f:
        IOError: [Errno 21] Is a directory: 'kk'

-> Fix that by teaching gpython to effectively use runpy.run_path
instead of unconditionally assuming that first non-optional argument is
path of a file. This adds support, similarly to how std python behaves,
for running directories with __main__.py and zip archives with
__main__.py inside.

We do not use runpy.run_path directly because that function stashes
installed __main__ module and uses fresh stub while running anything
with removing the stub after the run. For our situation, however, that
is incorrect, for example because with -i we need to inspect the state
left after running the workload. Implement our own runpy.run_path custom
analog ourselves to handle that correctly.

/fixes nexedi/pygolang#2
/reviewed-by @vnmabus, @jerome
/reviewed-on nexedi/pygolang!36