On 07/11/2011 01:36 PM William ML Leslie wrote:
On 11 July 2011 20:29, Bengt Richter<b...@oz.net> wrote:
On 07/10/2011 09:13 PM Laura Creighton wrote:
What do we want to happen when somebody -- say in a C extension -- takes
the id of an object
that is scheduled to be removed when the gc next runs?
IMO taking the id should increment the object ref counter
and prevent the garbage collection, until the id value itself is garbage
collected.
This significantly changes the meaning of id() in a way that will
break existing code.
Do you have an example of existing code that depends on the integer-cast
value of a dangling pointer??
Or do you mean that id's must be allowed to be compared == to integers,
which my example prohibits? (I didn't define __cmp__, BTW, just lazy ;-)
If you want an object reference, just use one. If you want them to be
persistent, build a dictionary from id to object.
Yes, dictionary is one way to bind an object and thus make sure its id is valid.
But it would be overkill to use a dictionary to guarantee object id persistence
just for the duration of an expression such as id(x.a) == id(y.a)
It might be unusual, but the .a could be a property returning a dynamic value
and you might be testing to see if the two return the same object, as they might
if the the property get caches such values. Perhaps it is a test to verify that
you
have the caching version of the app. Artificial example perhaps, but current id
could give false results, with id just pointing to the same dead temp space.
That's an example of code that would *fail* with the current id, and be ok with
id as either of Id or IdHold.
As it stands, the integer returned by id persists during evaluation
of an expression at least, but its validity does not necessarily last
with the value even that long, as we see from the perverse (but easily
explained) example:
>>> id([0]) == id([1])
True
>>> id([0]), id([1])
(3084230700L, 3084230700L)
So at a minimum, I would think the documentation should say that
an id call may return a value implicitly referencing garbage,
besides hinting that there may be peculiarities about id-ing some objects.
You can already do
this yourself in pure python, and it doesn't have the side-effect of
bloating id().
My examples *are* in pure python ;-)
Otherwise, such a suggestion should go through the usual process for
such a significant change to a language primitive.
Sure, but I only really want to understand the real (well, *intended* ;-)
meaning of the id function, so I am putting forth illustrative examples
to identify aspects of its current and possible behavior.
Also, a new id could live alongside the old ;-)
Regards,
Bengt Richter
--
William Leslie
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
