[Python-ideas] breaking out of module execution

[M.-A. Lemburg]

Nick Coghlan wrote:
> 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.

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 ?

* want to limit the available defined APIs based on flags or
  other settings ?

* want to make modules behave more like functions or classes ?

* want to debug import loops ?

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.

Esp. with the new importlib, tapping into the wealth of
functionality in that area has become a lot easier than before.
Only the compiler is preventing it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 25 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2012-04-28: PythonCamp 2012, Cologne, Germany               3 days to go
2012-04-25: Released eGenix mx Base 3.2.4         http://egenix.com/go27

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/