[Python-ideas] breaking out of module execution
Steven D'Aprano
steve at pearwood.info
Wed Apr 25 13:49:06 CEST 2012
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
More information about the Python-ideas
mailing list