[Python-ideas] breaking out of module execution

[Nick Coghlan]

On Wed, Apr 25, 2012 at 7:41 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Nick Coghlan wrote:
>> On Wed, Apr 25, 2012 at 10:55 AM, Steven D'Aprano <steve at pearwood.info> wrote:
>>> In my opinion, this is an attractive nuisance.
>>>
>>> -1 on the feature.
>>
>> Agreed (and my preferred idiom for all the cited cases is also "always
>> define the Python version, override at the end with the accelerated
>> version").
>
> IMO, defining things twice in the same module is not a very Pythonic
> way of designing Python software.
>
> Left aside the resource leakage, it also makes if difficult to find
> the implementation that actually gets used, bypasses "explicit is
> better than implicit", and it doesn't address possible side-effects
> of the definitions that you eventually override at the end of the
> module.
>
> Python is normally written with a top-to-bottom view in mind, where
> you don't expect things to suddenly change near the end.
>
> This is why we introduced decorators before the function definition,
> rather than place them after the function definition. It's also why
> we tend to put imports, globals, helpers at the top of the file.

I agree overwriting at the end isn't ideal, but I don't think allowing
returns at module level is a significant improvement. I'd rather see a
higher level approach that specifically set out to tackle the problem
of choosing between multiple implementations of a module at runtime
that cleanly supported *testing* all the implementations in a single
process, while still having one implementation that was used be
default.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia