En Wed, 28 Jan 2009 16:00:43 -0200, Scott David Daniels
<scott.dani...@acm.org> escribió:
Gabriel Genellina wrote:
En Wed, 28 Jan 2009 01:36:57 -0200, Steve Holden <st...@holdenweb.com>
escribió:
Gabriel Genellina wrote:
En Tue, 27 Jan 2009 22:17:16 -0200, Robert Kern
<robert.k...@gmail.com>
escribió:
I *thought* I did understand this until I came to this example:
1)
id(globals()), id(locals())
(11239760, 11239760)
This is a bad test. We know distinct objects are distinct, but:
>>> print id(object()), id(object())
10598120 10598120
>>> a = object(); b = object()
>>> print id(a), id(b)
10598120 10598128
The reason is that once your created object has its id taken, you
must keep a handle on it, otherwise it may get recycled and reused.
It doesn't matter in this case, I think. globals() is always the same
object and is alive during the whole test. So something having the same
id() than globals() must be the very same object, and something having a
different id() than globals() cannot be the same object.
If you like, I can rewrite the example without using id():
L = list(n for n in [globals(),locals()])
L[0] is L[1]
True
L = list(n() for n in [globals,locals])
L[0] is L[1]
False
(I *think* this has to do with free variables in the "right side" (after
the "in" keyword) of a generator expression; they appear to be evaluated
when the expression is *defined*, not when is is *used*. By contrast, free
variables in the "left side" appear to be evaluated when the expression is
used.)
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list