#1 Axis partitioner for formatting dates & times nicely
I have been doing quite a bit of work collecting data over
periods of days and weeks, an have started working on a
partitioner which produces nice looking time axes in PyX. I
am attaching the code, which should take very much
massaging to include in the main PyX distribution, if you
think this would be useful (I do). In the near future, I will
probably implement another partioner useful for data
extending over months & years (which will create non-
uniform partitions with ticks at real month boundaries,
etc.).
A sample of a web page which is being updated with this is:
http://129.59.235.188/~michael/Environmental.html
which shows some environmental data from our building.
Note that to get the most current graphs, you have to click
the 'update graphs' button, then go back to the original
page and refresh it. We are still developing the website, so
it is a little crude in the mechanistics.
Note that becasue of the way I have declared the format
strings as class globals, it is very easy to override the
formatting. The small sample subclass michaeltimepart is
the one being used on the webpage. The main difference
in this case is the slash in the month/day spec.
I prefer this method for handling variations to including all
possible information in the arguments to the constructor,
since python subclassing is so easy. If you would rather
handle format variations as arguments, the changes are
easy. Maybe the best bet would be to have format string
as arguments defaulted to None, in which case the class
defaults arre used, but if non-None formats are given, they
override the class defaults. This would allow both
programming styles.
Comments?
Marcus Mendenhall
corrected version (added necessary imports)
Logged In: YES
user_id=405853
Its nice to see your time partitioning ... indeed those axes
are an important feature to be added to PyX in the future. I
thought about this issue myself as well and there are users
outside which request it regulary (I myself included).
Indeed, the possibility to set ticks not only equal spaced
was a design decision quite some years ago having in mind
the example of months (with different length) already.
Recently I've played around with the new datetime module of
python 2.3 (I've installed the beta version at home), which
might be a good solution for implementing time axes. (I'm
not yet totally sure about it.) One feature would be, that
you could use something like strptime as well. You could
then overwrite the convert/invert of the axis. In good old
Python (<=2.2) a strptime is available in the time module
unter Unix only. I think a timeaxis should decode time
strings like dates (1.1.2000 etc.) without (or with only an
easy) additional efforts. Best would be, if you could just
say g = graph.graphxy(x=graph.timeaxis(), ...) and all works
out of the box. I definitly want that, but it will take some
time.
Additionally I'm currently working on texters (I want to
separate out the creation of label texts from the axis
painter). You're right with your solution, that labels for
the time axes can be created most easily in the partitioner,
but we could write a time texter as well, which does this
job. It definitly has to be taken out of the axispainter. I
prefer a texter solution. The axispainter is very ugly already.
Beside all this, let me briefly comment your proposed
solution about constructor arguments. You're totally right,
that it is nice to create classes with personal preferences.
PyX Power Users ;-) definitly want that. But what do you
think about doing it the following way:
class myaxispainter(graph.axispainter):
def init(self, zerolineattrs=None, args):
graph.axispainter(self, zerolineattrs=zerolineattrs,args)
The advantage is, that it behaves like the original
axispainter except for the default value of zerolineattrs
... I like this.
Logged In: YES
user_id=470295
I hadn't noticed the new datetime module in 2.3. It is certainly
trivial to make this us either time or datetime, since it really
mostly needs strftime, which exists in both.
The question about how general to make this, and how to allow
it to interpret different input time formats, is somewhat
philosophical. I soent a fair amount of time thinking about how
general to make my version (for now), and concluded that overly
general may not be too good. Unlike with many other options for
x-axes, one generally knows in advance what time ranges one
want to cover in a plot. If it is less than seconds, decimal time is
appropriate, and if it is more than years, the same uniform
division scheme is appropriate. It is only in a narrow range of
civil time scales (minutes to months) that we have pathological
divisions. Thus, making an axis formatter that specifically does
this range more beautifully and configurably was my goal.
If a completely general formatter is desired, maybe it should be a
set of classes which implement nice algorithms for each general
time range, and an autotimeaxis() which selects one of the
specific formatters. That way, if the user wants to force a specific
formatter (which in my case will almost always be the case), the
specific class can be instantiated, but if one wants a 'no worries'
axis, the wrapper can be called to select the right formatter.
Comments?
Logged In: YES
user_id=405853
I would like to see a solution, which does not mix the
partitioning of a time axis and the creation of the text for
the labels. I do understand, that this splitting might look
unnatural for the first time. But it increases usability (at
least I think so). Thus I'm not totally confident about your
patch. But I should remark, that I would have written
something very similar to your patch, when I would have
needed a quick & easy implementation of a time axis.
Concerning the new datetime data type(s) of Python 2.3 I
would like to see, that they replace the frac-instances for
time axes completely. This means to remove the explicit
usage of the frac instances at all those points, where they
are not strongly needed (for example in the axis painter).
The creation of text for the labels needs to be separated
from the axis painter, as I checked it in the CVS head last
weekend. I'll try to continue in writting code in that
direction during the next weeks. We'll see what happens in
terms of a datetime axis by that ...