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
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
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
