[Python-ideas] breaking out of module execution
zuo at chopin.edu.pl
Thu Apr 26 00:27:47 CEST 2012
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).
More information about the Python-ideas