Hi, On Sun, 2008-07-20 at 08:09 -1000, Eric Firing wrote: > It sounds like there is time to do it before the release without messing > up the release. Just make sure the backend_drivers.py test suite still > runs OK. If you can add tests (i.e., examples run by backend_drivers) > that exercise the new functionality, that is even better. The > interactive part of the functionality can't be tested in an automated > way, but the rest can, and adding an example is a good way to help users > see how to use it. In any case, go ahead and commit when ready. >
I have recommitted my changes to contour.py plus modifications to fix the problems you identified (r5799). I also included a couple of new pylab_examples that test the new interactive (ginput, etc.) and non-interactive (e.g., using a dictionary to specify label format) elements. The non-interactive pylab_example (contour_label_demo) has been integrated into backend_driver.py. This should hopefully help save me from myself. > Yes, the labeling code is difficult, and I have not looked at it in a > long time. If you are interested, please do look at it from the > standpoint of a possible major revision that might make it easier to > understand and easier to enhance. > For the moment, I have tried to add a few comments here and there that explain my understanding of things and identify some problems. One thing that should probably be fixed immediately is that the attribute names in ContourLabeler don't meet the standards in the coding guide (e.g., label_levels instead of clabelLevels) and are hard to understand (e.g., cl could be contourLevels instead of clabelLevels). I would like to fix these, but this may break user's code that depends, e.g., on CS.cl having that name. How much should I worry about this? There are likely few users that directly modify ContourSet properties, but you never know. I think changing these names and adding a few comments would at least pave the way for future improvements. I also have a couple of general questions for the group: 1) ginput currently returns a list of tuples instead of a two-column array of x,y coordinates. I think a numpy array is more intuitive and saves the user having to cast to array. Is there any reason why ginput should not return a numpy array instead of a list of tuples? 2) Can someone explain to me why is_string_like in the cbook doesn't just do isinstance(obj,str)? Is there anything "string like" that won't be caught be this isinstance call? Cheers, David -- ********************************** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ********************************** ------------------------------------------------------------------------- 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
