Ted Drain wrote: > We have some experience maintaining persistent object storage over long > periods of time. The best solution we've found is to do something like > this: > > - create a read/write method on each class. Every class that needs to be > stored must have this. This includes class you would store (eg Figure) and > things that are member variables of those classes. > > - Each class stores a version number along with it's data which represents > the version of the persistent representation for that class. So each class > has its own, internal versioning scheme that represents a specific set of > variables with specific types. > > - The read method on each class must check the version number and then read > the appropriate data for that version of itself. Whenever the persistent > representation of the class changes (usually if the member variables > change), you increment the version number. Implicit in this is that if you > change the member variables of a class, the class read method must be able > to convert the variables that existed in the older version of itself into > the new member variables (since that's what the new methods on that class > will be using) > > FYI It is possible to use pickle to do this but you can't rely on pickle to > automatically save the member dictionary. You need to implement > __getstate__ and __setstate__ and have them incorporate a version number in > the dictionary they return. In addition, you shouldn't blindly save every > member variable. If member variables can be constructed in terms of other > data, it may be better to store that data and then reconstruct the member > variables in the __setstate__ method. > > Using this type of system, you get a hierarchy of objects that each have > their own, internal versioning system. This lets you make changes to a > single class, increment it's version, and update its save/load methods and > it won't affect any other part of the system and still retains backwards > reading capability. > > Ted
Sounds good--for some applications--but I would strongly oppose adding this additional level of complexity to mpl. It's just not worth it. If you want to be able to work with a plot, then generate it with a script, and save the data and the script. That is the user's responsibility, not mpl's. Unless mpl is taken over by a cadre of full-time professional programmers, we have to try to keep it accessible to people who can only work on it sporadically. That means we need to try to keep it simple--indeed, to work on simplifying it and cleaning up the rough edges, and to work on maintaining a design that makes it easy to improve the real plotting capabilities and ease-of-use. Eric > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Eric Firing >> Sent: Tuesday, September 16, 2008 7:04 PM >> To: John Hunter >> Cc: Josef Koller; matplotlib-users@lists.sourceforge.net >> Subject: Re: [Matplotlib-users] save or pickle figure object >> >> John Hunter wrote: >>> On Tue, Sep 16, 2008 at 5:06 PM, Josef Koller <[EMAIL PROTECTED]> >> wrote: >>>> Hi folks, >>>> I would like to save preliminary figures for later processing and >>>> refinement with matplotlib. Is there a way to save or pickle a >> figure >>>> object and later reload it. Matlab has a feature like that and and I >> was >>>> wondering if matplotlib has it too. >>> No, it doesn't exist. We've taken a stab at it once or twice, but >>> have been stymied because we make extensive use of a python extension >>> libray CXX, and these objects have resisted our attempts to pickle >>> them. With our recent transforms refactoring, which removes the >>> hairiest CXX dependency, it may be worth taking another look, but >>> noone is currently working on it. >> My sense, based on very little experience, is that pickles of >> complicated objects are very fragile, so even if we could pickle >> figures, I fear it might cause more trouble ("I can't load this >> absolutely critical figure I pickled 6 months ago") than it would be >> worth. >> >> Eric >> >> ----------------------------------------------------------------------- >> -- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> Checked by AVG - http://www.avg.com >> Version: 8.0.169 / Virus Database: 270.6.21/1674 - Release Date: >> 9/16/2008 8:15 AM > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users