[C++-sig] additional files for pickle support

[Ralf W. Grosse-Kunstleve]

> Can we discuss different names for "pickle_support_base" please?
> I'm in favor of "pickler". Thus, world_pickle_support is-a
> boost::python::pickler. I realize it's also an unpickler, so if you don't
> like that I'd like to at least find a way to drop "_base" from any public
> names.

pickle_support_base -> pickle_group
.pickle_support() -> .def_pickle()

> 1. I don't see how your error message thing is going to cause a message to
> appear under any circumstance (?)

After renaming setstate to xxsetstate:

tru64cxx65-C++-action
/net/redbelly/scratch1/rwgk/bjam/libs/python/test/bin/pickle3_ext.so/tru64cxx65/debug/pickle3.o
cxx: Error:
/tmp_mnt/net/boa/home1/rwgk/boost_mpl_ublas/boost/python/object/pickle_support.hpp,
line 98: #135 
          class
          "boost::python::error_messages::missing_pickle_group_function_or_inco
          rrect_signature<boost::python::class_<<unnamed>::world,
          boost::python::detail::not_specified,
          ...

BTW: I think it would be nice if all compile-time error messages
were in namespace boost::python::error_messages .

> 2. Are users expected to call this "register_" function?
> It would be nice to avoid that.

The register_ function is now hidden in namespace detail. I could
not simply make it private because some compilers do not support
template friends.

> 3. How about a "curiously recursive template" formulation,
> ...
> struct pickle_world : pickle_support<pickle_world>

Cool trick! However, the user interface is more complicated than
it is in my current implementation:

struct world_pickle_group : pickle_group

> Question: Why not just have this function accept a tuple argument instead
> of doing your own error checking?
> 
>     static
>     void
>     setstate(world& w, boost::python::object state)
>     {
>         using namespace boost::python;
>         extract<tuple> state_proxy(state);
>         if (!state_proxy.check() || len(state_proxy()) != 1) {
>           PyErr_SetString(PyExc_ValueError,
>             "Unexpected argument in call to __setstate__.");
>           throw_error_already_set();
>         }

I chose object over tuple because I want my error message to appear
under as many circumstances as possible.

> > Locally I am currently working with
> > #include <boost/python/detail/api_placeholder.hpp>
> > This file implements len() and getattr(). I don't think you want this in
> cvs.
> 
> I guess not in the long run, but as a temporary measure it's fine.

OK, I am working towards checking in the complete set of patches.
(Then you can convince yourself that the compile-time error messages
really work.)

> I hope so. I'm going to try making class_<> into a class derived from
> object, to see how that goes. Then it would be:
> 
>     .attr("foo") = ... ;
> 
> Hmm, you can't just dump setattr, because the above won't chain. We could
> adopt a Phoenix-like construct:
> 
> ...
> 
> But I'm still nervous about that; I think it would put a huge burden on
> many compilers.

I am /very/ nervous about these ideas. It is highly important to us
that V2 will be stable enough for routine use as soon as possible.
Collaborators keep asking about V2 and is getting more and more
difficult to keep them interested. Maybe it is time to start a list
of potential V3 projects.
BTW: what is the status of the mpl1 -> mpl2 transition, and how
much instability will this generate for how long?

> Well, here's another one, which I'm sure you'll really love <wink>: used a
> named parameter interface like that used in Boost.Graph
> http://www.boost.org/libs/graph/doc/bgl_named_params.html

Cool trick again! However, the prime motivations behind the pickle_group
design are 1. to establish a formal grouping of the pickle/unpickle
functions and 2. to fully relieve the user from thinking about
the individual functions at the point of binding them via .def_pickle().
In addition we have the compile-time consistency checks (which is
the only reason for the requirement that the user pickle group must
inherit from boost::python::pickle_group).

> >   void class_base::enable_pickle_support(bool getstate_manages_dict)
> >   {
> >       setattr("__reduce__", make_instance_reduce_function());
> >       handle<> one(PyInt_FromLong(1));
> >       setattr("__safe_for_unpickling__", one);
> >       if (getstate_manages_dict) {
> >         setattr("__getstate_manages_dict__", one);
> >       }

BTW: I will change this to work with object as soon as setattr()
is modified accordingly.

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com