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 -- https://mail.python.org/mailman/listinfo/python-list