Function decorator that caches function results

[Steven D'Aprano]

On Sun, 09 Oct 2005 18:00:13 +0200, Fredrik Lundh wrote:

> Steven D'Aprano wrote:
> 
>> "Each def or lambda expression that is executed will create a closure if
>> the body of the function or any contained function has free variables."
>>
>> Presumably that means that if there are no free variables, no closure
>> is created.
> 
> you're quoting selectively; the word "closure" isn't used anywhere
> in the design document except for a section that talks about "flat
> closures", which is an implementation approach used in CPython
> (as the sentence before the one you quoted explains).

Given that when I asked about closures, you pointed me at that document
for further information, I thought maybe I could take it as authoritative.

> I don't think it's necessarily a good idea to treat a reference to an
> algorithm and an attribute on an object in a specific implementation as
> the definition of an computer term...

Are you suggesting that Jeremy Hylton got it wrong? That's fine if he did,
but it would help if you said so rather than beating around the bush.

Is it correct to say that Python creates closures *ever*?

Is it correct to say that Python creates closures when a def or lambda
statement is executed?

Is it correct to say that Python *always* creates a closure whenever a def
or lambda is executed? Or is it only for *certain* defs/lambdas?

Is it correct to talk about functions *having* closures, or that they
*are* closures, or that the function is *part of* a closure?

If all functions are closures, what does it mean to say that some
languages (e.g. Java, C++, C#) don't have closures but merely simulate
them? Are there any languages that don't have closures?


Thanks for your patience, I'm sure I'll get there eventually.




-- 
Steven.