[Python-ideas] making a module callable

[Eric Snow]

On Fri, Nov 22, 2013 at 9:07 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Fri, Nov 22, 2013 at 05:26:33PM -0700, Eric Snow wrote:
>
>> It's relevant because no one should be replacing __main__ in sys.modules. :)
>
> I see your smiley, which confuses me. Are you serious that replacing
> __main__ is a bad idea? If so, can you explain why?

I do think it's a bad idea.  It would be like replacing a builtin
module in sys.modules, which is inadvisable (particularly key ones
like sys).  Like builtins, __main__ is a special module, one created
during interpreter startup.  It plays a special part in the REPL.
Various parts of the stdlib have special-casing for __main__, which
could be affected by replacement.  Replacing __main__ in sys.modules
is, to me, just as inadvisable as replacing sys.

The catch is that a script is exec'ed into the __main__ module's
namespace, so during execution (nearly) all the import-related
attributes relate to __main__.  In contrast, the equivalent module
from the same file would be loaded into its own namespace, with its
own import-related attributes, and cached independently at
sys.modules[module_name].  This duality causes all sorts of grief (PEP
395 is a response to some of the pain points).  A key hangup is that
__name__ is different depending on run-as-script or
imported-as-module.

That brings us back to the idea of a more formal
replace-module-in-sys-modules API.  Any solution to that which uses
__name__ to determine the module's name has to take into account that
it may have been run as a script (where __name__ will be "__main__").
If we simply used __name__ staight up we might end up replacing
__main__ in sys.modules, which I suggest is a bad idea.  Hence the
point of special-casing __main__.

Sorry I wasn't clear.  Hopefully this was more so.

-eric