break in a module

[Erik Max Francis]

Eric Snow wrote:
> On Tue, Jun 14, 2011 at 5:51 PM, Erik Max Francis <max at alcyone.com> wrote:
>> Ethan Furman wrote:
>>> To me, too -- too bad it doesn't work:
>>>
>>> c:\temp>\python32\python early_abort.py
>>>  File "early_abort.py", line 7
>>>    return
>>>       ^
>>> SyntaxError: 'return' outside function
>> Nor should it.  There's nothing to return out of.
> 
> Perhaps we have a misunderstanding then.  The contents of a module
> file are the body of the module definition.  Like the body of any
> other complex statement, that body is going to get executed [1].
> 
> Some of the complex statements have keywords that let you break out of
> that execution, like break and continue in loops.  Some do not.

It's quite consistent on which control structures you can break out of 
-- it's the looping ones.

> However, there is most certainly something out of which to return, the
> execution of the module body.

You return out of functions or methods.  Not modules.

> I apologize if my example was unclear.  I kept it pretty simple.  I
> expect using __main__ was misleading.  However, this is by no means
> the only use case.  In general it would be nice to do some checks up
> front and decide whether or not to continue executing the module,
> rather than waiting until the end to decide:
> 
>   if condition_1:
>       ...
>       return
>   if condition_2:
>       ...
>       return
> 
>   # now do my expensive module stuff
> 
>   # finally handle being run as a script
>   if __name__ == "__main__":
>       ...
> 
> The only ways that I know of to accomplish this currently is either by
> putting everything inside if-else blocks, or raise some kind of
> ImportBreak exception and catch it in an import hook.

You're still not elucidating a very clear use case here.  You want to do 
some tests and then break out of the top-level execution of the module 
if they happen.  Just use `sys.exit`.

It's still not clear _why_ this is useful.  As I said, the typical 
behavior of a module is to define a lot of things, perhaps building up 
some needed data structures, and then do the `__name__ == "__main__"` 
test to see if it's being executed as a script, and then _do_ something. 
  So it's still not clear what tests you're trying to perform while 
defining the contents of the module (but before executing it as a 
script, should that be the case), and then exit.

The only situation where the execution of the contents of the module 
might vary with top-level branching tests is for portability or version 
reasons, say, checking `sys.platform` or `sys.version` and then doing 
different things depending on their values.  But these are easily 
handled with if/else structures -- or, if that gets unwieldy, using a 
lookup table -- and, at any rate, you're _not_ going to "break out of 
the module" once you've done that, you're going to continue on 
definition the non-(platform, version)-specific stuff, then test whether 
it's being run as a script, and then do something.

The only case I can see for exiting out of a module early would be if 
something exceptional happens that leads the module's internal logic to 
conclude that it can't be used.  But the solution there is 
straightforward:  Raise an exception.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   We have always been space travelers.
    -- Carl Sagan, 1934-1996