"A.M. Kuchling" wrote: > > Currently, when you replace a class definition with an updated > version, it's really difficult to change existing class instances; > you'd have to essentially sweep every Python object and check if it's > an instance, starting at roots such as __main__ and sys.modules. This > makes developing code in a long-running process difficult, Zope being > the best example of this. When you modify a class definition used by > Zope code, you can't update existing instances floating around in > memory. In the case of Zope, if the objects that you care about happen to be persistent objects, then it's relatively easy to arrange to get the objects flushed from memory and reloaded with the new classes. (There are some subtle issues to deal with, like worrying about multiple threads, but in a development environment, you can deal with these, for example, by limiting the server to one thread.) Note that this is really only a special case of a much larger problem. Reloading a module redefines the global variables in a module. It doesn't update any references to those global references from other places, such as instances or *other* modules. For example, imports like: from foo import spam are not updated when foo is reloaded. Maybe you are expecting too much from reload. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
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