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

Reply via email to