When do default parameters get their values set?

[Rustom Mody]

On Thursday, December 11, 2014 8:45:22 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 10 Dec 2014 18:18:44 -0800, Rustom Mody wrote:
> 
> 
> > And going the other way -- no defs only lambdas its this:
> > 
> > 
> >>>> f = lambda : (lambda x= {}: x)
> >>>> f()() is f()()
> > False
> >>>> d = f()
> >>>> d() is d()
> > True
> >>>> 
> >>>> 
> > 
> > But I have a different question -- can this be demonstrated without the
> > 'is'? 
> 
> 
> Can *what* be demonstrated? That the functions returned are different 
> objects, or that the dicts are different objects? Both? Something else?

What? Referential transparency (or the lack of it)
https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29

Or if you like it more technical: 
Python breaks referential transparency even in the absence of assignment

[From my (cursory) reading of the wikipedia page all the 
no-transparent examples need assignment (or IO) to demo the point]

> 
> Using "is" you are demonstrating that calling the function twice returns 
> two distinct objects. That is the purpose of "is", to compare object 
> identity. Without "is", you can compare object IDs directly:
> 
> id(f()()) == id(f()())
> 
> but that's ugly and less efficient. Using "is" is the more idiomatic and 
> natural way to do this.
> 
> 
> Other than that, you could do something to demonstrate the consequences 
> of the two values being distinct objects:
> 
> a = f()()  # Call twice to get a dict.
> b = f()()
> a['key'] = 23
> b['key']  # raises KeyError
> 
> 
> or
> 
> a = f()  # Call once to get a function.
> b = f()
> a.attribute = 23
> b.attribute  # raises AttributeError
> 
> 
> Or you could inspect the byte-code of f and try to understand it.
> 
> 
> 
> > Because to me 'is' -- equivalently id -- is a code-smell 
> 
> It is only a code-smell in the sense that caring about object identity 
> should be rare.

Yes. Its good we agree on that ;-)

In the FP world referential opaqueness is the name of the devil.
In the more 'real' imperative/OO world there's way too much of it.

Finding a middle-way remains an IMHO important open problem