John, It seems like a slightly different design and some refactoring of the code would help with this (of course that's WAY easier to say than it is to do). I'm thinking of something like this:
Public API layer: Very thin (i.e. minimum amount of code). The goal of this layer might be to transform various input types into a fixed set of data. This would include: - units to floats - various input data representations to a standard format. Like converting python lists to numpy arrays. - various input options to a standard format. Like the various marker, color, style input options into some standard representation. Private plotting layer: Fixed interface - doesn't support all the various options (lists, arrays, units, color codes, etc). Does the actual work of plotting. The public layer would just do conversions and then pass through to the private layer. Any code in the public layer would have to concern itself with possible different types (numpy vs lists, units vs floats, color names vs rgb). Any code written in the private layer could be assured of having some specific input types and would be much easier to write. It seems to have happened more than once that when some new chunk of code is added, there are a number of bugs that appear because that code is written with a single data type in mind (no units, no numpy arrays, etc). Having a clear layer where data types can be assured would help w/ that. Of course this would be a lot work and would require refactoring axis and maybe some of the collections. In theory it should be possible, but only you guys can decide if it's actually worthwhile or not. Ted > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > John Hunter > Sent: Monday, July 21, 2008 3:40 PM > To: Michael Droettboom > Cc: matplotlib development list; Eric Firing > Subject: Re: [matplotlib-devel] units support > > On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <[EMAIL PROTECTED]> > wrote: > > I'll second being confused at times. In the transformation > conversion, it > > was something I didn't know too much about up front, so it's quite > possible > > that I broke some things in that regard. (I know of some already, > but those > > were fixed shortly after things were merged into the trunk around > 0.98.0). > > All that is to say that you may want to cross-reference against > 0.91.x if > > things look fishy. But I think you're right, we need some sort of > "best > > practices" guidance for supporting units, and then hopefully just > track down > > all the places where "such-and-such" should be happening and isn't. > > I'll work on putting together a document for the developer's guide -- > how to support units in a plotting function and artist. Supporting > the units interface everywhere would definitely add to the memory > footprint of mpl and would slow it down, in addition to increasing the > coding burden. On the other hand, they are quite useful in some > cases, most notably for me working with native datetimes and hopefully > down the road a numpy datetime extension. Once I get the guide > written and provide some clarity on the interface, we can decide in > which functions it makes the most sense from a performance usability > perspective and clean those first. Perhaps there are additional > abstractions that can ease the coding burden, eg encapsulating all the > mask/unit/what-have-you logic into a single entity such as a location > array which supports a minimum set of operations. > > JDH > > JDH > > ----------------------------------------------------------------------- > -- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > Checked by AVG - http://www.avg.com > Version: 8.0.138 / Virus Database: 270.5.3/1564 - Release Date: > 7/21/2008 6:42 AM ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
