follow up on config file

Development matplotlib-devel
1

This might work as a compromise. Instead of using the

    > traits class, I wrote a quick and dirty Traits Lite(tm)
    > class. I think the traits class provided a lot more
    > functionality than was needed, and what was needed
    > required very little code.

OK, this is looking much more promising. I have given a quick glance
over and will test it more extensively this afternoon.

Quick comments. I'd like to continue using the matplotlib naming
convention (UpperCase) for class names, rather than underscore
separated

class trait_color(Trait):

also,

I don't think we should use the name Trait or HasTrait, since that
will confuse people into thinking we are using enthought traits
(Property and HasProperty ?)

Finally, another feature I would like to be able to support, which
won't be hard, is to enable the use of an RC class or something like
it in Artist constructors

Here is what we currently have

    def __init__(self, xdata, ydata,
                 linewidth = None, # default to rc
                 linestyle = None, # default to rc
                 color = None, # default to rc
...snip..
                 ):

This overloads None which leads to strange usages like
linestyle='None' to turn off lines (note the quotes). I would rather
do something like

    def __init__(self, xdata, ydata,
                 linewidth = RC('lines.linewidth'),
                 linestyle = RC('lines.linestyle')
...snip...
                 ):
                 if isinstance(linewidth, RC): linewidth=linewidth()

Note that this is different than

    def __init__(self, xdata, ydata,
                 linewidth = rc.lines.linewidth,
                 linestyle = rc.lines.linestyle,
...snip...
                 ):

The syntax above is not the point. What I want to emphasize is that I
want a self documenting way of saying this parameter defaults to an rc
param, and that param should be evaluated *at init time*. If you can
do it with the second syntax, that looks better, but if I read your
code correctly, something like rc.lines.linewidth evaluates to a float
at module load time and so cannot be used as a sentinel at module init
time. Is this correct?

In any case, it looks very promising. Two final comments. Like
Fernando, I'm not too concerned about being able to parse existing rc
files. It's a minor burden to require people simply to take the new
format and customize it. Also, do you need to extend the fontsize
train to support fontsizes in points, eg 12.0 ?

    > Sorry for sending in such a large file once again. I
    > wanted to be able to parse the entire RC file to make
    > sure that things were going to work okay.

No problem, I think we can handle it.

    > It still needs some work, but it's pretty functional for
    > a proof of concept. It's capable of parsing the RC file,
    > validating the type-assignment, and uses the
    > 'rc.lines.color = xxx' format. It's also fairly modular,
    > so additions should be easy.

Well if it already parses existing rc, no reason to kill it.

I look forward to looking more closely at it -- thanks!
JDH

2

John Hunter wrote:

Quick comments. I'd like to continue using the matplotlib naming
convention (UpperCase) for class names, rather than underscore
separated

Okay, I started to convert the names. I haven't yet done this for the more internal functions (i.e. things like lines_properties).

class trait_color(Trait):

also,

I don't think we should use the name Trait or HasTrait, since that
will confuse people into thinking we are using enthought traits
(Property and HasProperty ?)

Fair enough. I changed it to HasProperties and Property.. It's a little verbose, but I guess it won't be used very much outside of the file.

Finally, another feature I would like to be able to support, which
won't be hard, is to enable the use of an RC class or something like
it in Artist constructors

Here is what we currently have

   def __init__(self, xdata, ydata,
                linewidth = None, # default to rc
                linestyle = None, # default to rc
                color = None, # default to rc
...snip..
                ):

This overloads None which leads to strange usages like
linestyle='None' to turn off lines (note the quotes). I would rather
do something like

   def __init__(self, xdata, ydata,
                linewidth = RC('lines.linewidth'),
                linestyle = RC('lines.linestyle')
...snip...
                ):
                if isinstance(linewidth, RC): linewidth=linewidth()

Note that this is different than

   def __init__(self, xdata, ydata,
                linewidth = rc.lines.linewidth,
                linestyle = rc.lines.linestyle,
...snip...
                ):

Okay, I changed the HasProperties class to include a 'get()' function as well. This allows for:
rc.get('lines.linewidth') ==> a Property-subclass instance

The only problem with this, is that this might not be what the person is expecting. I could easily change the get function to instead return the value of the Property, but there are uses for getting the actual Property back as well.. Of course one can override the __float__, __int__, etc. methods, but this still requires explicit conversion, thus the user still has to know something about the internals.

My current solution was to add a function 'getValue', which is the same as get, but returns just the value. This could also very easily be wrapped up in a function:

def RC(name): return rc.getValue(name)

The syntax above is not the point. What I want to emphasize is that I
want a self documenting way of saying this parameter defaults to an rc
param, and that param should be evaluated *at init time*. If you can
do it with the second syntax, that looks better, but if I read your
code correctly, something like rc.lines.linewidth evaluates to a float
at module load time and so cannot be used as a sentinel at module init
time. Is this correct?

Nope, it keeps as a property, and thus has sentinel-capabilities.

In any case, it looks very promising. Two final comments. Like
Fernando, I'm not too concerned about being able to parse existing rc
files. It's a minor burden to require people simply to take the new
format and customize it. Also, do you need to extend the fontsize
train to support fontsizes in points, eg 12.0 ?

Currently it accepts either a float or one of the keywords. It should be fairly easy to extend it to also use the syntax '12.4pt' or '12in' (i.e. LaTeX style -- of course someone would have to write a conversion function..)

Well if it already parses existing rc, no reason to kill it.

As long as we keep the 1-to-1 mapping, it's easy enough to do. It's the same code (plus reading in the file) what is done for rc.get('x.y.z')

Abe

config4.py (18.4 KB)

3

John Hunter wrote"

I don't think we should use the name Trait or HasTrait, since that
will confuse people into thinking we are using enthought traits
(Property and HasProperty ?)

If I'm not mistaken, those are the names that the Trait package used
originally! They changed the name because of potential confusion with
Python properties. Isn't that still an issue?

Perry