Eric Snow wrote:
On Tue, Jun 14, 2011 at 5:51 PM, Erik Max Francis <m...@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 && m...@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
--
http://mail.python.org/mailman/listinfo/python-list
