#1 default args for data.(list|file)(x=1,y=2)

[Francisco Dellatorre Borges]

All graph data entries must have a x and y coordinates.

It would be more sensible to determine a default order
for these in the data so as to avoid the typing of
x=1,y=2 at every single data.(list|file) call.

Just as users (e.g. me) of a cmd line plotting routine
expect to call

$ bozoplot results.dat

with two columns entries:

0 1
1 3 etc

and have a graph plotting these as x, y. Users (e.g. I)
would expect to be able to call pyx.graph.graphxy.data.
methods without having to specify at every call which
is column x and which is y.

Francisco.

[Andre Wobst]

Logged In: YES
user_id=405853

Couldn't you do this within your bozoplot command? The point is that
graph.data.file and the like do not know anything about the column
names they need to fill with data. It's designed the other way around.
You provide some data and the graph styles (by the help of the axis
names available in the graph) will tell you, whether this is a valid
request. I do not want to stress that too much, especially since we
currently have an xy graph only, but the axis names could be completely
different in an polar plot, a 3-d plot etc. And other graph styles like text,
arrow, errorbars etc. want other data as well. I would not like to see a
semi-guessing solution in PyX. Comments?

[Jörg Lehmann]

Logged In: YES
user_id=390410

I agree with Andr. Such a policy should not be part
of the data component. In order to support quick&easy
plotting, a wrapper providing some standard plot types as
suggested recently by Michael Hagemann on the pyx-user is
the way to go.

[Francisco Dellatorre Borges]

Logged In: YES
user_id=576554

1. I think a wrapper would be nice and I thought about
   making one myself.

I have some code that already works as a wrapper but it's
scathered and as I need to deliver a thesis chapter by the
end of this month, I haven't actually started putting the
code pieces together.

1. Yet, I still would like to be able to code some things
   faster and a wrapper won't help much at it. When drawing
   some illustrative didactic graphs for my thesis, I end up
   calling data.list 4 or 5 times in a file, (and that's using
   attr.changelist([a,b,c]) to avoid extra calls as in:

g.plot([ data.list(i, x=1, y=2, text=3) for i in [pts, pts1,
pts2] ],
[st.line([attr.changelist(
[linewidth.thick, linewidth.normal,linewidth.normal] ),
attr.changelist(
[linestyle.solid, linestyle.dashdotted, linestyle.dashdotted
] )]),
st.text(textdx=0.5, textdy=0)])

Perhaps allow setting default values at a data.list instance
initialization and then allow more instances to be created
from this one?

dlst = data.list(None, x=1, y=2, dy=3) # setting default values.
g.plot(dlst(d1, text=4), style1)
g.plot(dlst(d2, stacked=4), style2)

I don't know exactly how this should be implemented, as you
seem to need different data.list objects to process, the
class object would have to became a object factory
separating the current data.list.init method into
init and call. Hackish solutions in this direction
would be easy to implement and a more clean version
shouldn't be too much of a problem.

[Andre Wobst]

Logged In: YES
user_id=405853

Sure, many things could be done. But we do not use call too much.
(There is a use case in the attribute modification and thats fine but I
don't know whether its appropriate at an data instance. May be ... could
be. It would be kind of a convenience method.)

But back to your problem: You could just "decorate" an arbitrary callable
thing by some additional keyword argument (when they are not
overwritten). This could look like that:

def decorate(callable, addkwargs):
def decorator(*args, kwargs):
fullkwargs = addkwargs.copy()
fullkwargs.update(kwargs)
callable(args, *fullkwargs)
return decorator

def test(args, *kwargs):
print args, kwargs

test(1, 2, a=1, b=2)
testdeco = decorate(test, b=-2, c=-3)
testdeco(1, 2, a=1, b=2)

A way to go for you?

Beside that, Jrg, what's your opinion about making a data instance
callable to create a new data instance out of an existing one. Thats what
graph.data.data is for right now. But using graph.data.data we do not
keep the old columns ...

[Andre Wobst]

Logged In: YES
user_id=405853

Still, data.data is the proposed solution here. Anyway, I've modified its
behaviour to (by default) keep the original columns with their names. This
adds additional flexibility and you now can give the axis names in the data
files without repeating them in PyX. I think its about all we should do.