[Python-ideas] breaking out of module execution

[Jan Kaliszewski]

M.-A. Lemburg dixit (2012-04-25, 12:37):

> Isn't that an application developer choice to make rather than
> one that we force upon the developer and one which only addresses
> a single use case (having multiple implementation variants in a
> module) ?
> 
> What about other use cases, where you e.g.
> 
> * know that the subsequent function/class definitions are going to
>   fail, because your runtime environment doesn't provide the
>   needed functionality ?

IMHO then you should refactor your module into a few smaller ones.

> * want to limit the available defined APIs based on flags or
>   other settings ?

As above if there are many and/or long variants. Otherwise top-level
if/else should be sufficient.

> * want to make modules behave more like functions or classes ?

What for? Use functions or classes then.

> * want to debug import loops ?

Don't we have some good ways and tools to do it anyway?

> Since the module body is run more or less like a function or
> class body, it seems natural to allow the same statements
> available there in modules as well.

Function body and class body are completely different stories.

* The former can contain return, the latter not (and IMHO this
limitation is a good thing -- see below...).

* The former is executed many times (each time creating a new local
namespace); the latter is executed immediately and only once.

* The former takes some input (arguments) and returns some output;
the latter is a container for some callables and/or some data.

* The former is mostly relatively small; the latter is often quite
large (breaking execution flow of large bodies is often described as a
bad practice, and not without good reasons).

Modules resomehow similar to singleton classes (instantiated with
the first import).

Cheers.
*j