> I've seen the matplotlib code, and have used a fair number of
>> plotting >libraries in my day. The matplotlib results are
>> wonderful, but the API is a bit goofy, don't you think? Does
>> FigureCanvas->Figure->Axes make sense to you? I'd be OK with
>> two of those, but I don't understand how three possibly
>> helps.
>>
>> I don't think it's goofy at all. You have FigureCanvas because
>> seperating out the thing that "draws" the figure is the best
>> way to implement backend neutrality. You have Figure and Axes
>> (rather than just Axes) because that's the best way to
>> implement things like subplots, plotting overlapped axes, and
>> figimage(), colorbars, and figure legends.
> I think we agree: the hierarchy is implementation driven,
> not use driven.
It depends on your perspective I guess. Originally there was only a
Figure and Axes, and when we started supporting other backends than
GTK (eg WX) we needed to segregate the Figure from it's container to
provide a GUI independent way of representing the Figure. In my view,
this was a use driven detail, since we wanted to use matplotlib with
other GUIs, but you may view it as an implementation driven, which it
is also.
If you are only using matplotlib in a single context, eg a WX App,
then yes, it is more overhead than you need. But it is fairly useful
in a GUI neutral plotting library.
Because the GUI neutrality imposes some extra syntactic overhead when
working with OO matplotlib, I think it is a good idea to have GUI
specific OO wrappers to ease the common tasks, like you and Ken have
provided.
JDH