XML

Development matplotlib-devel
1

Hi. I've found myself in the position of (a) often having

    > to plot data with specific views for either debugging or
    > publication purposes. While this is often easy enough to
    > write as a python script, I've found myself either
    > rewritting the same code over again, or having to create
    > a large number of command line parameters to specify
    > exactly what type of plot is required. It occured to me
    > that it might be nice to have a seperation of data and
    > plotting (i.e. MVC) and that XML would work well for
    > these purposes (e.g. libglade and renaissance) . For
    > 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.

    > p.s. I've had the traits-based config library almost done
    > for a bit .. I just haven't had time to put the last
    > finishing touches on it. I'll email it soon.

Great.

2

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.

   > p.s. I've had the traits-based config library almost done
   > for a bit .. I just haven't had time to put the last
   > 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

3

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

···

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.