OK, I'm +1 on the "Won't fix" status.

I'm not proficient enough in the way unpickling works, but the fact that you cannot specify any namespace in which classes or functions names have to be resolved makes it quite clear that dynamic imports + unpickling functions and classes = not possible.

Regards,
Nicolas

2006/3/29, Deron Meranda <[EMAIL PROTECTED]>:
On 3/29/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> Are you okay with:
>
>   http://issues.apache.org/jira/browse/MODPYTHON-81
>
>   Pickling/unpickling top-level functions defined in published
>   module no longer works in mod_python 3.2
>
> being resolved as "Won't Fix" and then closed?

I agree that this seems to be something that is just not
solvable without causing complete havoc with all the
specialized import and reload functionality, or resulting
in a solution that is too fragile.  It is just a limitation of
the pickle mechanism.

This of course doesn't mean that users wouldn't want to
pickle these kinds of things.  But that the burden in those
cases should be on them.  It may be possible to solve
this for class instances (e.g., objects) by subclassing the
Unpickler class and substituting a smarter find_class()
method.  But as for globals, functions, etc., it looks like
it may be much harder.

The user may also be able to take advantage of the
external object pickling (with persistent ids), but I
haven't looked at them too closely.

Regardless, there are lots of alternatives, so I have
no problem with mod_python not solving this one
(although the mod_python documentation should
clearly emphasize these pickling limitiations).
--
Deron Meranda

Reply via email to