Hi, I committed the changes to clabel (r5830). For the attribute renaming, I think we can safely rename most of them. In my opinion, the only ones that users might use are .cl, .cl_xy and .cl_cvalues. The clabel function creates these just before finishing from their more appropriately named versions. This should provide enough backward compatibility for a release or two.
And yes, isvector is different from iterable. For example: In [81]: cbook.isvector( array([3,4,5,6]).reshape(1,1,1,4) ) Out[81]: True In [82]: cbook.isvector( array([3,4,5,6]).reshape(1,1,2,2) ) Out[82]: False This function is probably more useful in matlab since it has no shape way to distinguish vectors from 2D matrices, but still it doesn't hurt to have it around. Cheers, David On Wed, 2008-07-23 at 08:08 -1000, Eric Firing wrote: > John Hunter wrote: > > On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> Well, I now know more than I ever wanted to about clabel. I decided to > >> improve a bit on the inlining and ended up rewriting it. For automatic > >> label placement, I basically use the existing algorithm for determining > >> label location, but have replaced existing code for determining the > >> angle of rotation and the amount of the contour to take off for inlining > >> with new code. This new code is based on using pixel-space distances > >> along the contour. This allows one to (1) get nice balanced inlining > >> with the same amount of space on either side of the label, and (2) to > >> vary the amount of space you want around the label. It also should deal > >> better with labels located near contour edges and labels covering the > >> entire contour. > > It all sounds like much-needed improvement. > > >> > >> Along the way, I renamed all ContourLabeler specific attributes to > >> something like .labelAttribute. This makes the namespace cleaner in my > >> mind, but might break existing user code that does things directly with > >> ContourLabeler attributes. > > > > Eric, do you have any sense of whether people would use this directly? > > I think the probability that anyone is doing this is low, but it would > be nice to ask on the users mailing list. > > > Since this is a point release, I want to minimize API breakage, so at > > least keep the old attrs around for this cycle. Eg, in Axes I > > recently renamed axesPatch to simply patch as follows: > > > > # the patch draws the background of the axes. we want this to > > # be below the other artists; the axesPatch name is deprecated > > self.patch = self.axesPatch = self._gen_axes_patch() > > > > we don't have an easy way to catch deprecated usage w/o some property > > or getattr magic. If you want to add getter properties for the > > deprecated attrs which warn and point to the new, that would be ideal. > > In general, yes, but in this case I think it would be better to go with > your simpler method above, of making duplicate names. It reduces the > code clutter and the chance of introducing last-minute errors. The > mailing list and API_CHANGES can be used to notify users of the upcoming > deprecation. If there is an outcry, indicating wide use of the > attributes, then properties can be introduced later to smooth the > deprecation process. But I predict there will be hardly a peep. > > > > > > >> I also added a few new functions to cbook. One does simple linear > >> interpolation (in addition to an existing cbook function that is similar > >> but a bit different). Others do things with vector lengths. I also > Maybe explain in the docstring or a comment why this version is needed? > >> added a function called isvector that is identical to a Matlab function > Maybe use try/except to return False if the test fails? If the input is > a string, or None, for example? Whether to do this depends on what the > use case is. > >> of the same name. If desired, I can move this to mlab.py, but for the > >> moment it is in cbook.py because most of the is? functions are there. > > > > That's fine. Is this different from "iterable" > > > >> On an aside, I noted that mlab.norm uses cut-and-paste documentation > >> from Matlab. Is this wise? > > > > No, please rewrite the docstring. Some of mlab was borrowed form > > other people's codes, and I was unaware of this. > > norm is one of the things we should not have at all; ours should be > deprecated in favor of numpy.linalg.norm. It would be good to have a > linear algebra guru look at this to see whether a straight substitution > with deprecation warning would work, or whether there are significant > differences. If something close to a substitution will work, then the > docstring in mlab can be replaced with a reference to the numpy > function. And then in some future release, it will all be deleted. > > > > >> I have tested all the changes against the existing pylab_examples and > >> things work fine. Nonetheless, since lots of things have been changed, > >> I haven't committed them for fear of interfering with the release. > >> Instead, I am attaching the patch set. If I get the green light, I will > >> commit these changes. > > > Given the stated "release early, release often" strategy, go ahead and > commit. > > Eric > > > I'll leve the final call on this to Eric, but after this I suggest we > > implement a feature freeze until after we get the current code tested > > and out. Friday is a reasonable target if others agree and we have a > > chance to test this for a couple of days. > > > >> Related: while I am digging around in there, now is probably the moment > >> for me to integrate Paul Kienzle's comments on start/stop_event_loop in > >> FigureCanvasBase, etc. I am not sure there is a consensus on this. I > >> am currently thinking that the best way to integrate this, while > >> minimizing repeated code, is a mixin plus a couple of new classes, > >> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would > >> inherit the mixin and the base classes without "GUI". Interactive > >> backends would then inherit these. Non-interactive backends would > >> inherit versions that throw errors from FigureBaseCanvas. Complex, but > >> this assures clean inheritance. Thoughts welcome. > > > > See my response in the original thread. I'm not sure we ever reached > > a consensus on this one, and I'm still uncomfortable with a more > > complex hierarchy. I'm willing to be convince if you and Paul and > > Gael disagree, but I have yet to see why a flat implementation will > > not work here. > > > > 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 > -- ********************************** 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
