John Hunter wrote: [...] > > The code is trying to add a non-unitized quantity (eg an errorbar > width but just guessing) of int type with a unitized quantity > TaggedValue (this is from the mockup basic_units testing package). > You'd have to dig a little bit to find out where the non-unitized > quantity is entering. errorbar is a complex example that was once > (and I think still is) working on the 91 branch. You may want to > compare the errorbar function on the branch vs the trunk and see what > new feature and code change broke the units support. Again, it might > be cleaner to have an ErrorbarItem that stores the errorbar function > inputs and updates artist primitives on unit change rather than try > and propagate the original unitized data down to the artist layer. As > Eric suggested, doing these one at a time is probably a good idea, and > errorbar is a good test case because it is so damned hairy :-)
One of the reasons for doing all the conversions at the higher level than the primitive artist is that often one *has* to do the conversion at that higher level in order to do the calculations required to draw the item; so a consequence of putting the conversion in the primitive artists is that the conversion facilities have to live at *both* levels, which makes the code harder to understand and maintain. The only penalty in taking the conversion out of the primitive artists is that a user who wants to support units in a custom plot type, using primitive artists, must include the unit conversion etc. I don't think this is a big problem for new code, though, because if the conversion is at that higher level only, then it is easy to show how to do it (there will be plenty of examples), and to ensure that there are enough helper functions to make it easy to code. Maybe there already are. Or maybe deriving from a PlotItem base class would make it easier. (Or maybe this is a place where decorators would simplify things? Just a random idea, not thought out.) Eric ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
