On Fri, 25 May 2012 10:21:39 -0700 Ethan Furman wrote:

I'd like to make a slight doc change for weakref to state (more or less):

weakrefs are not invalidated when the strong refs are gone, but rather when garbage collection reclaims the object

Should this be accurate for all implementations, or should it be more along the lines of:

weakrefs may be invalidated as soon as the strong refs are gone, but may last until garbage collection reclaims the object

How about: weakrefs are invalidated when the object is destroyed, either as a product of all the strong references being gone or the object being reclaimed by the :term:`cyclic garbage collector <garbage collection>`. Regards Antoine.

Ethan Furman wrote:

I'd like to make a slight doc change for weakref to state (more or less):

What specific part of the docs are you planning to change? My guess is that you want to change this start of the third paragraph: http://docs.python.org/py3k/library/weakref.html [quote] A weak reference to an object is not enough to keep the object alive: when the only remaining references to a referent are weak references, garbage collection is free to destroy the referent and reuse its memory for something else. [end quote] I don't think that should be changed. It makes no promises except that weak refs won't keep an object alive. Everything else is an implementation detail, as it should be.

weakrefs are not invalidated when the strong refs are gone, but rather when garbage collection reclaims the object

I think you're making a distinction here that we should not make. Reference counting *is* a garbage collector (even if gc-bigots like to sneer at ref counting as "not a real gc"), and implementations with such a ref counting gc will not always distinguish the two states "strong refs are gone" and "object is reclaimed". I don't believe that we need to make promises about the exact timing of when weak refs will be invalidated.

Should this be accurate for all implementations, or should it be more along the lines of:

weakrefs may be invalidated as soon as the strong refs are gone, but may last until garbage collection reclaims the object

This is better than the previous suggestion, since it says "may" rather than implies a "will". -- Steven