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