On Wed, Apr 25, 2012 at 6:30 AM, Steven D'Aprano <steve@pearwood.info> wrote:
- encourages premature micro-optimization, or at least the illusion of optimization - hard to use correctly, hence code using this feature risks being buggy - encourages premature micro-optimization, or at least the illusion of optimization - encourages or requires duplicate code and copy-and-paste programming - complicates the top-level program flow
Today, if you successfully import a module, you know that all the top-level code in that module was executed. If this feature is added, you cannot be sure what top-level code was reached unless you scan through all the code above it.
This got me thinking "well, you get the same thing with functions and the return statement". Then I realized there's a problem with that line of thinking and stepped back. Modules and functions have distinct purposes (by design) and we shouldn't help make that distinction blurrier. We should (and mostly do) teach the concept of a module as a top-level (singleton) namespace definition. The idioms presented in this thread mostly bear this out. Python doesn't force the distinction syntactically, nor am I suggesting it should. However, it seems to me that this not how most people think of modules. The culprit here is the lack of distinction between modules and scripts. If a module is like a class, a script is like a function. Perhaps we should consider ways of making the difference between scripts and modules clearer, whether in the docs, with syntax, or otherwise. -eric