Re: Idea: Autorun functionality for Python modules (redux)

On 23 May 2017 at 20:47, Petr Viktorin <[email protected]> wrote:
> I have two nitpicks:
> 1) __main__.__autorun__ is quite a weird place to store interpreter-level
> configuration.

Fair point when it comes to the idea as posted, but I wasn't actually
intending for it to be interpreter level configuration:

Instead, I'd expect runpy.run_path() and run_module() to *always* set
`__autorun__=True`, to indicate they were going to implicitly invoke
any `__run__` method definitions, without having to mess with the name
of the module they're executing.

Thus, __autorun__ would be a "Running a module as a script" setting,
and "__main__.__autorun__" would get set by virtue of it being a
module getting run as a script, rather than by virtue of it
specifically being the main module.

> 2) AFAIU, `if __name__ == "__main__"` is an obscure implementation detail
> (answer to "what should be the name of a nameless module?"), reified by
> people relying on it. It would be nice to try to downgrade it to being just
> an implementation detail again.

Unfortunately, __main__ also gets used as "the place to access
application wide config settings" (by way of the "import __main__"
approach), so I don't think we're ever going to get away from that
name twiddling for the actual __main__ module.

I *do* think we can get rid of (or at least deemphasise) it for the
runpy APIs though - I just missed that I'd left that aspect of the
design rationale out of the initial post.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia