Re: variables bound in moudules are None when module is not completely imported
On Tue, Feb 24, 2009 at 03:27:19PM +0100, chr...@fsfe.org wrote: * is there a workaround? * especially, is there a workaround that works w/o rewriting the modules that raise the exceptions? (otherwise, wrapping all the stuff called in the __name__==__main__ wrapper into a main() function and then calling that would trivially solve that) update: i've found one, but this only works if the exception is raised at a point determined by the outside. to explain why this is applicable: in the examples, i used `1/0` to raise a zero division exception inside the module whose scope i want to preserve. in my practical application, the exception is thrown by a function that was previously prepared by the outside module and monkey patched to where the inner module is expected to call a method from (in my case, the gtk main loop). now if the function raising the exception saves both `sys._getframe().f_back.f_globals` and a .copy() of that dictionary, the original dictionary can later (when the exception is caught and the module's globals are all None) be .update()d with the copy, and the original module globals are restored. as said, this is just a workaround -- the original question still remains open. regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: variables bound in moudules are None when module is not completely imported
En Wed, 25 Feb 2009 16:48:16 -0200, chr...@fsfe.org escribió: update: i've found one, but this only works if the exception is raised at a point determined by the outside. to explain why this is applicable: in the examples, i used `1/0` to raise a zero division exception inside the module whose scope i want to preserve. in my practical application, the exception is thrown by a function that was previously prepared by the outside module and monkey patched to where the inner module is expected to call a method from (in my case, the gtk main loop). now if the function raising the exception saves both `sys._getframe().f_back.f_globals` and a .copy() of that dictionary, the original dictionary can later (when the exception is caught and the module's globals are all None) be .update()d with the copy, and the original module globals are restored. That makes a strange situation where the module doesn't exist in sys.modules but its globals are still alive... as said, this is just a workaround -- the original question still remains open. I'd try to move all the global stuff in that module into a function, init. Importing the module will always succeed - you have to manually call init() after importing it. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: variables bound in moudules are None when module is not completely imported
On Wed, Feb 25, 2009 at 05:05:28PM -0200, Gabriel Genellina wrote: I'd try to move all the global stuff in that module into a function, init. Importing the module will always succeed - you have to manually call init() after importing it. i normally do that anyway and would also have done so here (afaik, it's best practice anyway), but this is in this case not possible as the modules in question are not under my control at all. as pep 299 has been turned down, this can't really be considered a bug of those files. anyway, it would just be another workaround around the globals disappearing. That makes a strange situation where the module doesn't exist in sys.modules but its globals are still alive... is this a known bug? i mean from a garbage collection / refcount point of view, at least everything that is still referenced somewhere should be preserved. thanks chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: variables bound in moudules are None when module is not completely imported
En Wed, 25 Feb 2009 21:24:33 -0200, chr...@fsfe.org escribió: On Wed, Feb 25, 2009 at 05:05:28PM -0200, Gabriel Genellina wrote: I'd try to move all the global stuff in that module into a function, init. Importing the module will always succeed - you have to manually call init() after importing it. i normally do that anyway and would also have done so here (afaik, it's best practice anyway), but this is in this case not possible as the modules in question are not under my control at all. as pep 299 has been turned down, this can't really be considered a bug of those files. You might ask the module author for this feature... At least, try to move the registration at the end, after any code likely to raise exceptions. anyway, it would just be another workaround around the globals disappearing. That makes a strange situation where the module doesn't exist in sys.modules but its globals are still alive... is this a known bug? Not that I know. i mean from a garbage collection / refcount point of view, at least everything that is still referenced somewhere should be preserved. In older Python versions, an error when importing a module could leave a module object in sys.module partially initialized. That's very bad! Now, the entry in sys.modules is removed in such cases. Note that functions and classes defined inside a module don't have a reference to the module itself - their __module__ attribute is a string (although functions *do* have a reference to the module namespace, as you have remarked). So the entry in sys.modules is likely to be the last and only reference, and when it's removed, the module is deleted. This is a very tricky operation and at some stage involves setting all globals to None; if not were for any external references (like a callback registered somewhere else, as in your case) the module plus the functions and classes and objects defined inside it plus its global namespace, all of these should disappear, kaput, gone. You should report it at http://bugs.python.org -- I don't think this is likely to be fixed now, but at least it's on record. And when someone attempts to improve the module destruction sequence, there is a better chance this is taken into account too. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
variables bound in moudules are None when module is not completely imported
when a module being loaded is interrupted by an exception, code blocks that have the module's scope in their environment will later evaluate variables bound to that module to None, instead of preserving that scope (because it is still referenced somewhere) or raising a NameError (for which i see no reason, but which would still be better than silently returning None). this can happen, for example, when one tries to join different programs in one main loop by having the modules first hook up to events and then terminating the subprograms by replacing the call to the main loop with an exception raiser. attached, there is a tarball with two similar examples, one demonstrating that with functions instead of modules (this behaves as expected; ./function/), the other showing that when a module's block is terminated, the remaining variables are set to None (./module/); both can be run by calling `python main.py` in the respective directory. * is this a bug in the pythin implementation? (i've tested it both with 2.5 and with 3.0b2) * if yes, is it identical to [1748015]? (i suppose it is, but lacking experience with pdb i am not sure) * can / will this be fixed? * is there a workaround? * especially, is there a workaround that works w/o rewriting the modules that raise the exceptions? (otherwise, wrapping all the stuff called in the __name__==__main__ wrapper into a main() function and then calling that would trivially solve that) answers to any of these questions would be very much appreciated regards chrysn [1748015] http://bugs.python.org/issue1748015 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom module_none.tar.bz2 Description: Binary data signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
