Nicolas Lehuen
nicolas.lehuen at gmail.com
Tue Oct 4 02:23:16 EDT 2005
OK, I get it. So either we revert back to the sys.modules hell that we had in 3.1, or we just say that "pickling functions or classes that are defined in published module is not supported". This means that our good friend Gator Aide (what a fun pseudo) could solve his problem by defining the functions and classes he wants to pickle in a separate module, reachable from the Python path, and imported in the published module as a default module. Regards, Nicolas 2005/10/4, Graham Dumpleton <grahamd at dscpl.com.au>: > > Nicolas Lehuen wrote .. > > > > As explained in the error message, function objects can't be pickled. > This > > is not a mod_python limitation, rather a Python limitation. > > Hmmm, the pickle module documentation at: > > http://docs.python.org/lib/node66.html > > says: > > The following types can be pickled: > > ... > > - functions defined at the top level of a module > > It does however say: > > Note that functions (built-in and user-defined) are pickled by ``fully > qualified'' name reference, not by value. This means that only the > function name is pickled, along with the name of module the function is > defined in. Neither the function's code, nor any of its function > attributes are pickled. Thus the defining module must be importable in > the unpickling environment, and the module must contain the named > object, otherwise an exception will be raised. > > Note the requirement on the module being importable in the unpickling > environment. Since it wasn't imported and present in "sys.modules" to > begin with, I would say it is able to detect the potential for problems at > pickling time instead of later. > > But then, I could still be wrong. :-) > > Graham > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20051004/06a534ad/attachment.html
|