Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!feeder2.ecngs.de!ecngs!feeder.ecngs.de!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <20150802035327.GA53036@cskk.homeip.net>
References: <20150802035327.GA53036@cskk.homeip.net>
Date: Sun, 2 Aug 2015 14:12:11 +1000
Subject: Re: __main__ vs official module name: distinct module instances
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1152.1438488735.3674.python-list@python.org>
Lines: 39
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94886

On Sun, Aug 2, 2015 at 1:53 PM, Cameron Simpson <cs@zip.com.au> wrote:
> What are the implications of modifying the python invocation:
>
>  python -m cs.app.maildb
>
> to effectively do this (Python pseudo code):
>
>  M = importlib.import("cs.app.maildb")
>  M.__name__ = '__main__'
>  sys.modules['__main__'] = M
>
> i.e. import the module by name, but bind it to _both_ "cs.app.maildb" and
> "__main__" in sys.modules. And of course hack .__name__ to support the
> standard boilerplate.
>
> This would save some confusion when the module is invoked from the python
> command line and also imported by the code; it is not intuitive that those
> two things give you distinct module instances.
>
> Aside from the module's .__name__ being '__main__' even when accessed by the
> code as cs.app.maildb, are there other implications to such a change that
> would break real world code?

That's the one implication that comes to mind. It breaks the invariant
that "import X; X.__name__" should be the string form of X. But does
anything ever actually depend on that, or do things depend on the
weaker requirement that X.__name__ should be something which you can
import to get back a reference to X?

I'd support this proposal. I'm not seeing any glaring problems, and it
does have the potential to prevent bizarre problems. It would still
want to be a non-recommended course of action, though, as the change
won't (presumably) be backported - so any code that assumes that
importing its main file gives the same module as __main__ will
silently do the wrong thing on Python 2.7.

Toss it out onto -ideas and see what bounces back!

ChrisA