[Python-ideas] breaking out of module execution

Mark Shannon mark at hotpy.org
Wed Apr 25 14:43:08 CEST 2012


Steven D'Aprano wrote:
> Mark Shannon wrote:
>> Steven D'Aprano wrote:
>>
>> [snip]
>>
>>> Unless you address the disadvantages and costs of top level return, 
>>> you won't convince me, and I doubt you will convince many others.
>>>
>>
>> What costs?
> 
> Quoting from my post earlier today:
> 
> 
> [quote]
> Even if break at the module level is useful on rare occasions, I think 
> the usefulness is far outweighed by the costs:
> 
> - 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

I would have taken these to be the disadvantages, rather costs.
By costs, I assumed you meant implementation effort or runtime overhead.

Also, I don't see the difference between a return in a module, and a 
return in a function. Both terminate execution and return to the caller. 
Why do these four points apply to module-level returns any more than 
function-level returns?

> 
> 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.
> [end quote]

I don't know if this is a good idea or not, but the fact that to it can
be implemented by removing a single restriction in the compiler suggests
it might have some merit.

Cheers,
Mark.



More information about the Python-ideas mailing list