Deprecating reload() ???

David MacQuigg dmq at gain.com
Sat Mar 13 13:27:25 EST 2004


On Sat, 13 Mar 2004 10:30:04 -0600, Skip Montanaro <skip at pobox.com>
wrote:
>
>    Dave> How about if we could just show the reference counts on all of the
>    Dave> reloaded objects?  
>
>That wouldn't work for immutable objects which can be shared.  Ints come to
>mind, but short strings are interned, some tuples are shared, maybe some
>floats, and of course None, True and False are.  You will have to define a
>subset of object types to display.

Just to make sure I understand this, I think what you are saying is
that if I have a module M1 that defines a value x = 3.1, it will be
impossible to keep track of the number of references to M1.x because
the object '3.1' may have other references to it from other modules
which use the same constant 3.1.  This really does make it impossible
to do a complete reload.

I'm not sure at this point if an improved reload() is worth pursuing,
but perhaps we could do something with a "debug" mode in which the
minuscule benefit of creating these shared references is bypassed, at
least for the modules that are in "debug mode".  Then it would be
possible to check after each reload and pop a warning:

>>> reload(M1)
<module 'M1' from 'M1.pyc'>
Warning:  References to objects in the old module still exist:
M1.x  (3)
M1.y  (2)
>>>

Even if we don't update all the references after a reload, it would
sure be nice to have a warning like this.  We could then avoid
creating direct (not fully-qualified) references to objects within any
module that is likely to be reloaded, and be assured that we will get
a warning if we miss one.

-- Dave




More information about the Python-list mailing list