I posted a solution to the Trac ticket (7608) that is somewhat
different. The solution I posted probably isn't ideal, but it works.
I'd love to figure out a cleaner one.
The real trouble wasn't in determining between Graphs and DiGraphs,
but rather it was around multiedges or not. For instance, networkx
0.99 removed the XGraph class but there were two classes to replace it
depending on whether it was supposed to have multiple edges or not. As
far as I can tell, this couldn't be tested for until the data was
loaded into the object, so setting a function as the unpickle override
wouldn't help much.
Some googling didn't turn up any stories/solutions for migration, but
that doesn't mean there aren't any either.
I'd love to get a database of graph, poset, etc. pickles to test
against as well.
- Greg
On Jan 30, 5:52 am, "Nicolas M. Thiery" <nicolas.thi...@u-psud.fr>
wrote:
> Dear Greg, dear Franco,
>
> Short summary for the Sage-Combinat devs:
>
> Greg is upgrading networkx to 1.0 in Sage, and this is causing some
> unpickling issues for dynkin diagrams, crystals, posets, ...
>
> Short of any good solution, I think we do not have (yet) any important
> pickle of crystals or dynkin diagrams around, so keeping backward
> compatibility is not a strong issue for those.
>
> Anyone around having a large database of Poset pickles?
>
> On Fri, Jan 29, 2010 at 03:51:37PM -0800, Greg McWhirter wrote:
> > Ah, ok then, thanks. =) Found the issue and almost solved it. Added
>
> > from sage.structure.sage_object import register_unpickle_override
> > import networkx.classes
> > register_unpickle_override('networkx.xgraph','XGraph',
> > networkx.classes.Graph, call_name=('networkx.classes','Graph'))
> > register_unpickle_override('networkx.xdigraph','XDiGraph',
> > networkx.classes.DiGraph, call_name=('networkx.classes','DiGraph'))
>
> > to the graph_backends.py
>
> Cool!
>
> > This will pass the tests but it still isn't quite right. The issue is
> > in unpickling graphs with multiple edges. Due to the nature of the
> > networkx library changes, unpickling a graph with multiple edges
> > results in one without multiple edges which is broken when calling
> > edges() on it.
>
> > I was thinking of writing a translation class that would take whatever
> > input from either of the two deprecated classes. Then, to use it,
> > require the user to call a convert() method or something on it, which
> > would return the proper networkx class with appropriate data. This
> > seems less than ideal, however, and some sort of post-unpickle hook
> > would seem better, but poking around it doesn't seem that one exists.
> > I would love suggestions for other ways to solve this.
>
> Hopefully you can hack the __setstate__ method of networkx's new
> DiGraph class to fix the pickle state if it corresponds to an old
> networkx pickle, and leave it as is are otherwise. If it is hard to
> detect between the two, you could specify in
> register_unpickle_override a function (instead of DiGraph), which
> would create an empty DiGraph object with just one attribute
> self._unpickling_from_networkx_0_3=True that __setstate__ could test
> upon. See the pickle protocol for details:
>
> http://docs.python.org/library/pickle.html
>
> Just a question: are we the only one around having backward
> compatibility issue in the switch from networkx 0.3 and 1.0? I would
> have expected others to have already resolved this problem. Is it
> just that we waited too long before trying to upgrade?
>
> Cheers,
> Nicolas
> --
> Nicolas M. Thi ry "Isil" <nthi...@users.sf.net>http://Nicolas.Thiery.name/
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
