Deprecating reload() ???

John Roth newsgroups at jhrothjr.com
Fri Mar 12 13:24:21 EST 2004


"David MacQuigg" <dmq at gain.com> wrote in message
news:hgr3501a1qu612fvumq5ccd0vrocdoc4pf at 4ax.com...
> On Fri, 12 Mar 2004 08:20:14 -0600, Skip Montanaro <skip at pobox.com>
> wrote:
>
> >Given Python's current object model it would be an interesting challenge
to
> >write a "super reload" which could identify all the objects created as a
> >side effect of importing a module and for those with multiple references,
> >locate those other references by traversing the known object spaces, then
> >perform the import and finally rebind the references found in the first
> >step.  I thought I saw something like this posted in a previous thread on
> >this subject.
>
> I'm not familiar with the internals of Python, but I was assuming that
> all objects could be easily associated with the module which created
> them.  If not, maybe what we need is the ability to put a selected
> module in "debug" mode and keep a list of all objects created by that
> module and all references to those objects.  That would add a little
> overhead, but avoid the difficulties of searching all object spaces
> with every reload.

That's actually the wrong end of the problem. Even if you
could associate all the objects with the module that created
them, you would still have to find all the references to those
modules. That's the harder of the two tasks.

It's actually relatively easy to find the objects that would have
to be replaced: it's all of the objects that are bound at the module
level in the module you're replacing. Since CPython uses memory
addresses as IDs, it's trivially easy to stick them in a dictionary and
compare them while scanning all the places they could possibly be
bound.

John Roth
>
> -- Dave
>





More information about the Python-list mailing list