[Python-ideas] breaking out of module execution

[Steven D'Aprano]

M.-A. Lemburg 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.

You're not defining things twice in the same module. You're designing them 
twice in two modules, one in Python and one in a C extension module.

Your own example does the same thing. The only difference is that you try to 
avoid creating the pure-Python versions if you don't need them, but you still 
have the source code for them in the module.


> Left aside the resource leakage, 

What resource leakage?

If I do this:

def f(): pass
from module import f

then the first function f is garbage collected and there is no resource leakage.

As for the rest of your post, I'm afraid that I find most of it "not even 
wrong" so I won't address it directly. I will say this:

I'm sure you can come up with all sorts of reasons for not liking the current 
idiom of "define pure-Python code first, then replace with accelerated C 
version if available", e.g. extremely unlikely scenarios for code that has 
side-effects that you might want to avoid. That's all fine. The argument is 
not that there is never a use for a top level return, or that alternatives are 
perfect. The argument is that a top level return has more disadvantages than 
advantages.

Unless you address the disadvantages and costs of top level return, you won't 
convince me, and I doubt you will convince many others.




-- 
Steven