matplotlib-devel Mailing List for matplotlib

On Fri, Feb 25, 2005 at 02:04:57PM -0500, Abraham Schneider wrote:
> Hmm.. you make good points. Generally I think it is better to keep 
> everything within python when possible (plus I am not a big fan of 
> XML..). I suspect in the end this ends up being a preference issue, but 
> here is the advantage I see with XML. Suppose I have code that reads 
> data from a file, and can display that data in several different views 
> (e.g. different variables, different outlays, etc. depending on what is 
> being examined). In the past I have written a seperate python program 
> per view that I need or allowed command line parameters to be passed.
> 
> The difficulty with having separate python programs:
> * Will have to either:
> + run a different program per view I want
> + pass a python program as a parameter to run (I don't want to have 
> to edit the main program for each new view have another import .. I 
> suppose one could put them all in the same directory, but this could be 
> a hassle for quick hacks). This isn't a big deal, since I've essentially 
> already advocated this for the config files. Somehow the semantics of 
> doing so under these circumstances seems different to me, and perhaps 
> more userfriendly to provide a layout language.
> + continually reedit the same file with different parameters
> 
> On the other hand, if everything is passed on the command line, I have 
> found it is difficult to get enough specifity to plot exactly I want, 
> without requiring several lines worth of parameters.
> 
> So I see XML as a means of separating the layout of the data and 
> managing the different views, without having to touch the code at all. 
> In the end it doesn't really provide anything new, except for a 
> different method of doing the same thing.
> 
Python imports don't have to be static, you can access modules dynamically
just like you would XML files. For our web application we keep per-client
information in .py files that gets __import__'d to modify the look & feel,
setup default email addresses, etc. The modules just have to have some
agreed on names. If they have a particular function it gets called with
an object they can tweak.
ex/
def apply_custom(client_id):
 try:
 custom = __import__('client_%d' % (client_id))
 except ImportError: # nothing custom
 return
 def NOP(*args): return # do nothing function
 getattr(custom, 'alter_skin', NOP)(skin_object)
 getattr(custom, 'add_reports', NOP)(report_list)
 # etc
The upshot is that you can use python modules just like you would
use XML. They both contain markup, just different kinds.
-Jack
 

Hmm.. you make good points. Generally I think it is better to keep 
everything within python when possible (plus I am not a big fan of 
XML..). I suspect in the end this ends up being a preference issue, but 
here is the advantage I see with XML. Suppose I have code that reads 
data from a file, and can display that data in several different views 
(e.g. different variables, different outlays, etc. depending on what is 
being examined). In the past I have written a seperate python program 
per view that I need or allowed command line parameters to be passed.
The difficulty with having separate python programs:
* Will have to either:
 + run a different program per view I want
 + pass a python program as a parameter to run (I don't want to have 
to edit the main program for each new view have another import .. I 
suppose one could put them all in the same directory, but this could be 
a hassle for quick hacks). This isn't a big deal, since I've essentially 
already advocated this for the config files. Somehow the semantics of 
doing so under these circumstances seems different to me, and perhaps 
more userfriendly to provide a layout language.
 + continually reedit the same file with different parameters
On the other hand, if everything is passed on the command line, I have 
found it is difficult to get enough specifity to plot exactly I want, 
without requiring several lines worth of parameters.
So I see XML as a means of separating the layout of the data and 
managing the different views, without having to touch the code at all. 
In the end it doesn't really provide anything new, except for a 
different method of doing the same thing.
Abe
John Hunter wrote:
>My initial response to something like this, which I've seen before in
>the context of mpl, is: what is the advantage of using a XML over
>python? Except for the plot command, which specifies a read data and
>filename, everything is pretty much a literal translation of python.
>My suggestion would be to create custom python classes that build your
>figures, and use python 
>
>class PlotItem:
> def __init__(self, fn, fname, var, color, lw): 
> ... do something with it
>
>class SubplotItem:
> def __init__(self, title, pos)
> ....contains one or more plot items
>
>class FigureItem:
> def __init__(self, title)
> ... contains one or more axes items
>
> 
>fig = FigureItem(title="Hodgkin and Huxley cell")
>sub = SubplotItem(title="voltage" pos="1,1")
>fig.add_subplot(sub)
>plot = PlotItem(fn="readData" file="sim.dat", var="voltage")
>sub.add_plot(fig)
>
>and so on. Then you have the full power of python to specify your
>configuration layer. What does an XML layer buy you? I could see
>it's usefulness if you were trying to develop a GUI tool to edit and
>configure your figures....
>
>There has been some interest in having a way to save a figure state to
>an external file and open it where you left off. An XML
>representation might be useful there, in that it would ease the
>development of figure editors in a way that a pickled version would
>not.
>
>
> Abraham> p.s. I've had the traits-based config library almost done
> Abraham> for a bit .. I just haven't had time to put the last
> Abraham> finishing touches on it. I'll email it soon.
>
>Great.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Hi. I've found myself in the position of (a) often having
 Abraham> to plot data with specific views for either debugging or
 Abraham> publication purposes. While this is often easy enough to
 Abraham> write as a python script, I've found myself either
 Abraham> rewritting the same code over again, or having to create
 Abraham> a large number of command line parameters to specify
 Abraham> exactly what type of plot is required. It occured to me
 Abraham> that it might be nice to have a seperation of data and
 Abraham> plotting (i.e. MVC) and that XML would work well for
 Abraham> these purposes (e.g. libglade and renaissance) . For
 Abraham> example, something like:
My initial response to something like this, which I've seen before in
the context of mpl, is: what is the advantage of using a XML over
python? Except for the plot command, which specifies a read data and
filename, everything is pretty much a literal translation of python.
My suggestion would be to create custom python classes that build your
figures, and use python 
class PlotItem:
 def __init__(self, fn, fname, var, color, lw): 
 ... do something with it
class SubplotItem:
 def __init__(self, title, pos)
 ....contains one or more plot items
class FigureItem:
 def __init__(self, title)
 ... contains one or more axes items
 
fig = FigureItem(title="Hodgkin and Huxley cell")
sub = SubplotItem(title="voltage" pos="1,1")
fig.add_subplot(sub)
plot = PlotItem(fn="readData" file="sim.dat", var="voltage")
sub.add_plot(fig)
and so on. Then you have the full power of python to specify your
configuration layer. What does an XML layer buy you? I could see
it's usefulness if you were trying to develop a GUI tool to edit and
configure your figures....
There has been some interest in having a way to save a figure state to
an external file and open it where you left off. An XML
representation might be useful there, in that it would ease the
development of figure editors in a way that a pickled version would
not.
 Abraham> p.s. I've had the traits-based config library almost done
 Abraham> for a bit .. I just haven't had time to put the last
 Abraham> finishing touches on it. I'll email it soon.
Great.