[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