[IPython-dev] Getting InteractiveShell to clean up after itself

Brian Granger ellisonbg.net@gmail....
Wed Aug 26 14:17:06 CDT 2009


> 1. While I'm all for using more weakrefs, they are a subtle tool and I
> doubt we can get away with using them everywhere for everything.  I
> don't want to 'bet the farm' on that strategy, because we can easily
> find a situation where weakrefs don't work, we have way too much
> user-facing  state managemnet we must accomplish robustly and weakrefs
> may not be the tool for everything we need to do.
>

Yes, I agree.  When I proposed to use them "everywhere" I was actually
thinking quite narrowly.  Here is what I am thinking:

* Components will track children and parents using weakrefs.
* Component.get_instances will have an interface for getting a weakref.
Component holds the instances as weakref anyways,
so this is trivial.
* When Components need to hold onto a ref to each other they should be a
weakref.

Because InteractiveShell is a Component, no-one should hold a strong ref to
it under
this approach.


> 2. This is my favorite.  I wouldn't make the shell necessarily a
> context manager by itself yet, I'm not sure it's the right interface
> (I tend to prefer objects that have small, well-defined interfaces by
> themselves), but it would be easy, and good, to have a context manager
> that manages a shell instance for us and cleans it up on exit.
>

Yes, I like this.  For now, I am just adding a .cleanup method.  We can add
the context manager later.

Also, it would be very nice to be able to manage lots of other things with
"with":

io traps
sys hooks
threading locks (we are going to have to make InteractiveShell thread safe
with locks)
etc.

More evidence that dropping 2.4 support makes sense.


> How does this sound?
>

Great!  Thanks for the feedback.



>
> Cheers,
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20090826/d6379d78/attachment.html 


More information about the IPython-dev mailing list