On 13.01.04, Magnus Lie Hetland wrote:
> How does it currently work with more than one set of attributes, then?
> Do you use several keyword arguments?
Yes. For example axis painters in the graph module take a hole lot of
different attributes lists (painting the baseline, the gridlines, the
ticks, the labels, the axis title ...) as lists in keyword arguments.
> > But consider a decorator, which fills some arbitrary
> > path and writes a label into the filled area. Hence there are two
> > distinct fill operations in this example. Now you would need to use
> > keyword arguments taking lists of attributes with no excuse, wouldn't
> > you? (In the graph module, e.g. the axis painters and graph styles,
> > those constructs are quite common.)
> In a quick glance through the docs I didn't find exactly what you're
> talking about. Are you saying that you have a list of lists, then?
> attrs=[[foo, bar, baz], # First set of attributes
> [fie, foe, fum]] # Second set of attributes
> This could, of course, be easily dealt with without the attrs kwd.
> argument too:
> somedecorator([foo, bar, baz], [fie, foe, fum])
> But I guess you're probably talking about something else...?
What I was talking about was something like
So yes, keyword arguments best here.
Let me briefly explain this stupid list of list things (I consider
this a wrong design and tell you below, what I think we want to do in
the future). But lets first see, that we currently have. Consider you
draw a grid within a graph (e.g. lines for ticks and subticks). The
idea of ticks, subticks etc. is, that there can be arbitrary levels
of sub-sub-sub-ticks. There is a gridattrs attribute of the painter.
You can set gridattrs=[style.linestyle.solid, color.rgb.green] turning
on all grid lines of any level to be painted solid green. But thats
not always wanted. You can also write:
For ticks the first list is used, for subticks the second one. You can
also have None attributes, even for the first "list":
which leads to grid lines for the subticks only.
Although this works, we do have to provide other, so called changeable
attributes, somewhere else, and could make use of it at that point as
well. When you plot several functions, you want to have an automatic
change of the linestyle (solid, dashed, etc.). Consider a
multistroke-function, which takes a list of paths, and attributes to
be used when stroking this paths:
multistroke([path1, path2, path3],
A palette is a construct, which returns a color depending on a
parameter (in the range 0 to 1). The multistroke would evaluate the
changeable attribute for the different paths separately resulting the
different paths to be stroked in different colors. Those things are
possible in the graph styles. We could make that techniques generic
and use them for the axis painters and the different tick and label
levels as well ...
> > Additionally, I'm against private *args and **kwargs handling (and
> > mixing them both in one method at all).
> Really? Why? (And, by the way, what do you mean by "private" in this
This is kind of difficult to catch, since you need to address a case,
where you want to specialize an already existing function by adding
more arguments (however, this is a typical case when using
inheritance). Consider a function f having only keyword arguments:
f(arg1=1, arg2=2, arg3=3): pass
Now you want to overwrite this method but call the inherited method.
The new method may get further attributes, but pass other attributes
with a variable keyword argument:
g(arg4=4, arg5=5, **kwargs):
You can also modify some keyword args from f:
g(arg4=4, arg5=5, arg1=3, **kwargs):
Not, that for all other kwargs of f you do *not* have to repeat the
default values; you do not even know about them! This is very
beautyfull. However, there are two things you have to restrict
- You can not mix this with variable position arguments (*args).
- You can not split **kwargs to be used for several different calls.
This is basically a restriction, that you can do use this technique
with single inheritance only (you may use multiple inheritance, but
this delegation of keyword arguments is restricted to a call of one
inherited member function only).
We may discuss this further (I may not have thought about all
problems/possibilities well enough), but this might not belong to
pyx-user (as the origional RFC question about PyX's attribute system
does, although already this topic is quite technical for a users
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/