On 17 Dec 2001, Michael Hudson wrote: > barry@zope.com (Barry A. Warsaw) writes: > > > >>>>> "GvR" == Guido van Rossum <guido@python.org> writes: > > > > GvR> I haven't been following this discussion. Can you give a > > GvR> clear definition of The Right Thing? > > > > I think we need to define the goals of unloading. > > Doesn't that make it into a solution in search of a problem? > > When is unloading useful? I'm not being facetious, I've just never > been hit by the need for it. Shared libraries in XlispStat support unloading. But all of the times I've ever used it, I've used it as a 'reload' : usually while debugging shared libs -- it's handy to keep the interpreter window running while you fix and recompile a bug and load it again. The only case I can thing of where I might use it in production code would also be for a reload, where you might have several alternate 'plugin' modules. When you do an unload, references to objects that were in the shared library are replaced by references to a stub that generates an error/exception. ( That stub routine is part of the builtin dynamic load "module" . ) It doesn't involve traceing all the references -- the pointers are unchanged, but the object is changed. I have no idea what 'the Right Thing' for Python would be here -- I'm not quite clear on what you're trying to fix. I'm just volunteering an example. -- Steve Majewski
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4