Sorry to raise this touchy subject again, but I'm now trying to work around it in a somewhat different direction.
There are circumstances in which I want to (a) create a storage based on a file and then (b) later delete this file. Of course I know that once the file is gone, then anything based on it (any views left hanging arount, etc.) are invalid. But that's okay. Now it turns out that I have a "viewer" module for such a storage. If I invoke this viewer (as a top-level wxPython frame) it instantiates some classes, one of which eventually opens the storage via 'metakit.storage(name, mode)'. Then I close the viewer window. Now I *thought* this would make the storage object go away -- but apparently not, since if I then try to delete the file the storage is based on I get an exception and investigation shows that the storage (or something pertaining to it) is holding the file open. I can duplicate this behavior exactly just by opening any file-based storage and then trying to delete the file. And that's how it *should* work, of course. What I *don't* understand is why the storage is still hanging around once I close the frame that created the class instance in which the storage is created. There's only the one reference to the storage (buried in that class instance) and the only instance of that class is created in the viewer, and the viewer is now gone. But obviously the storage is still hanging onto the file resource. This is hardly Metakit's problem. So I figured that I'd just circumvent all these storage lifetime problems I've been having by managing all storage references myself. And after some thought it looked as though a nice way to approach this would be to maintain only one storage object per file (or one storage object per file/mode pair), and when any part of the program wants to "create" a storage for a given file, it finds (or creates) that single storage object and returns a proxy (weak reference) to it. Then, if I ever need to clobber a storage object at least I know exactly where it is and that there is only *one* reference to it. I think this would work quite well except for one thing: "Cannot create weak reference to 'PyStorage' object". So now my question is this: Are weak references to PyStorage objects unsupported simply because the necessary stuff to support them was just never added? (It doesn't *look* as though it would take much to support this.) Or is there some more fundamental reason weak references to PyStorage objects can't be supported? -------------------------------------- Gary H. Merrill Director and Principal Scientist, New Applications Data Exploration Sciences GlaxoSmithKline Inc. (919) 483-8456 _____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
