[Python-ideas] breaking out of module execution

[Eric Snow]

On Wed, Apr 25, 2012 at 6:30 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> - encourages premature micro-optimization, or at least the illusion of
>  optimization
> - hard to use correctly, hence code using this feature risks being buggy
> - encourages premature micro-optimization, or at least the illusion of
>  optimization
> - encourages or requires duplicate code and copy-and-paste programming
> - complicates the top-level program flow
>
> Today, if you successfully import a module, you know that all the top-level code in
> that module was executed. If this feature is added, you cannot be sure what top-level
> code was reached unless you scan through all the code above it.


This got me thinking "well, you get the same thing with functions and
the return statement".  Then I realized there's a problem with that
line of thinking and stepped back.

Modules and functions have distinct purposes (by design) and we
shouldn't help make that distinction blurrier.  We should (and mostly
do) teach the concept of a module as a top-level (singleton) namespace
definition.  The idioms presented in this thread mostly bear this out.

Python doesn't force the distinction syntactically, nor am I
suggesting it should.  However, it seems to me that this not how most
people think of modules.  The culprit here is the lack of distinction
between modules and scripts.  If a module is like a class, a script is
like a function.  Perhaps we should consider ways of making the
difference between scripts and modules clearer, whether in the docs,
with syntax, or otherwise.

-eric