Here is a bug report related to the output of setp(axes().get_yticklabels()), the complaint is that you can set the size but size is not listed. https://sourceforge.net/tracker/index.php?func=detail&aid=1357969&group_id=80706&atid=560720 The reason is that TextWithDash has a Text object attribute and delegates most of its methods to that object via __getattr__ and __setattr__. Can anyone tell me why this approach was favored over deriving TextWithDash from Text? Thanks, Darren
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> The reason is that TextWithDash has a Text object Darren> attribute and delegates most of its methods to that object Darren> via __getattr__ and __setattr__. Can anyone tell me why Darren> this approach was favored over deriving TextWithDash from Darren> Text? I think __getattr__ and __setattr__ are mostly evil since they lead to hard to debug code and break things like tab completion in ipython and object inspection. I'm +1 for refactoring TextWiithDashes to use inheritance or otherwise expose the attributes directly. JDH
On Tuesday 21 March 2006 18:53, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> The reason is that TextWithDash has a Text object > Darren> attribute and delegates most of its methods to that object > Darren> via __getattr__ and __setattr__. Can anyone tell me why > Darren> this approach was favored over deriving TextWithDash from > Darren> Text? > > I think __getattr__ and __setattr__ are mostly evil since they lead to > hard to debug code and break things like tab completion in ipython and > object inspection. I'm +1 for refactoring TextWiithDashes to use > inheritance or otherwise expose the attributes directly. OK, I refactored TextWithDash, and my changes passed backend_driver.py. setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206. The old TextWithDash is still there, but masked, just in case. Darren
On Wednesday 22 March 2006 09:49, Darren Dale wrote: > On Tuesday 21 March 2006 18:53, John Hunter wrote: > > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > > > Darren> The reason is that TextWithDash has a Text object > > Darren> attribute and delegates most of its methods to that object > > Darren> via __getattr__ and __setattr__. Can anyone tell me why > > Darren> this approach was favored over deriving TextWithDash from > > Darren> Text? > > > > I think __getattr__ and __setattr__ are mostly evil since they lead to > > hard to debug code and break things like tab completion in ipython and > > object inspection. I'm +1 for refactoring TextWiithDashes to use > > inheritance or otherwise expose the attributes directly. > > OK, I refactored TextWithDash, and my changes passed backend_driver.py. > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206. > The old TextWithDash is still there, but masked, just in case. Strike that, John found a bug that was exposed by dashtick. I reverted back to the old behavior.
On Wednesday 22 March 2006 14:24, Darren Dale wrote: > On Wednesday 22 March 2006 09:49, Darren Dale wrote: > > On Tuesday 21 March 2006 18:53, John Hunter wrote: > > > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > > > > > Darren> The reason is that TextWithDash has a Text object > > > Darren> attribute and delegates most of its methods to that object > > > Darren> via __getattr__ and __setattr__. Can anyone tell me why > > > Darren> this approach was favored over deriving TextWithDash from > > > Darren> Text? > > > > > > I think __getattr__ and __setattr__ are mostly evil since they lead to > > > hard to debug code and break things like tab completion in ipython and > > > object inspection. I'm +1 for refactoring TextWiithDashes to use > > > inheritance or otherwise expose the attributes directly. > > > > OK, I refactored TextWithDash, and my changes passed backend_driver.py. > > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206. > > The old TextWithDash is still there, but masked, just in case. > > Strike that, John found a bug that was exposed by dashtick. I reverted back > to the old behavior. I fixed the bug John pointed out, and unmasked the refactored version of TextWithDash in svn 2226. Darren
Darren Dale <dd...@co...> writes: >> > OK, I refactored TextWithDash, and my changes passed backend_driver.py. >> > setp(axes().get_yticklabels()) gives a comprehensive list as of svn 2206. > > I fixed the bug John pointed out, and unmasked the refactored version of > TextWithDash in svn 2226. Yes, 'size' is listed in the output now. However, now it seems that there are too many things listed: label: any string text: string The commands setp(gca().get_yticklabels()[0], 'label', 'foo') and setp(..., 'text', 'foo') do nothing. Of course, the right way to modify the tick labels is to call gca().set_yticklabels(['foo',...]) (or setp(gca(), 'yticklabels', ['foo',...])) which does quite some magic to change the label text (e.g., the Axis object's major formatter is changed into FixedFormatter(ticklabels)). Having 'label' and 'text' listed in the setp output could mislead people. However, if you draw a TextWithDash yourself, you _can_ change the text with setp, and indeed the docstring claims that TextWithDash is "intended to be a drop-in replacement for Text". E.g., the following works: t=text(1,1,'foo',withdash=True); setp(t,'text', 'bar'); So it wouldn't be right to simply remove set_text from TextWithDash, which would otherwise have been my suggestion. -- Jouni
>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes: Jouni> Darren Dale <dd...@co...> writes: >>> > OK, I refactored TextWithDash, and my changes passed >>> backend_driver.py. > setp(axes().get_yticklabels()) gives a >>> comprehensive list as of svn 2206. >> I fixed the bug John pointed out, and unmasked the refactored >> version of TextWithDash in svn 2226. Jouni> Yes, 'size' is listed in the output now. However, now it Jouni> seems that there are too many things listed: Jouni> label: any string Jouni> text: string If I'm reading this right, this has nothing to do with Darren's recent refactoring. a 'label' is a property of any matplotlib.artist.Artist (the base class for Line2D, Patch, Text, etc), and is used to attach a string to any object that renders into a figure (including the Figure itself). This is most used for auto-legending plot(x1, y1, 'go', label='label x') plot(x1, y1, 'rs', label='label y') legend() and legend will "to the right thing"(TM) In other cases, we might use the label in outputting group information in SVG output for instance, where we have open and close tags associated with polygons, etc.. So the label is not necessarily rendered into the figure, although it might be as the legend example illustrates, but is useful to tag objects with strings. matplotlib.text.Text.set_text, however, does set the to-be-rendered string for the Text instance. It is right and good that the text instance has a separate label and text property, though I agree this might be confusing on a cursory 'setp' or 'getp' introspection. JDH
John Hunter <jdh...@ac...> writes:
> Jouni> label: any string
> Jouni> text: string
>
> a 'label' is a property of any matplotlib.artist.Artist (the base
> class for Line2D, Patch, Text, etc), and is used to attach a string to
> any object that renders into a figure (including the Figure itself).
> This is most used for auto-legending
Oh, of course. I was confused by the name "tick labels" for the text
that accompanies tick marks.
> matplotlib.text.Text.set_text, however, does set the to-be-rendered
> string for the Text instance.
It doesn't seem to work for tick labels. E.g.
gca().get_xticklabels()[0].set_text('foo')
has no effect. This is quite understandable, since the text comes from
a Formatter object. It might be a neat hack to have set_text('foo')
automatically call set_xticklabels(['foo',...]).
--
Jouni
On Thursday 30 March 2006 3:44 am, Jouni K Seppanen wrote:
> John Hunter <jdh...@ac...> writes:
> > Jouni> label: any string
> > Jouni> text: string
> >
> > a 'label' is a property of any matplotlib.artist.Artist (the base
> > class for Line2D, Patch, Text, etc), and is used to attach a string to
> > any object that renders into a figure (including the Figure itself).
> > This is most used for auto-legending
>
> Oh, of course. I was confused by the name "tick labels" for the text
> that accompanies tick marks.
>
> > matplotlib.text.Text.set_text, however, does set the to-be-rendered
> > string for the Text instance.
>
> It doesn't seem to work for tick labels. E.g.
>
> gca().get_xticklabels()[0].set_text('foo')
>
> has no effect. This is quite understandable, since the text comes from
> a Formatter object. It might be a neat hack to have set_text('foo')
> automatically call set_xticklabels(['foo',...]).
I dont think that can work, since set_xticklabels(['foo',...]) makes its own
call to set_text('foo').
>>>>> "Darren" == Darren Dale <dd...@co...> writes:
Darren> I dont think that can work, since
Darren> set_xticklabels(['foo',...]) makes its own call to
Darren> set_text('foo').
ax.set_xticklabels calls ax.xaxis.set_ticklabels which creates a new
Formatter with
self.set_major_formatter( FixedFormatter(ticklabels) )
ticklabels are kind of funny, and this is related to the question on
the user's list about setting the location of ticklabels. The
location and string are determined at draw time by the Locator and
Formatter class, which is why well-intentioned but naive attempts to
control their location and text directly often fail. One has to set
the locator and formatter, and this is highly configurable and
customizable. For the most part, I think it works fine.
The one use case brought up on the users list that the framework
doesn't address is the "centering" issue of ticklabels, trying to get
the labels centered between ticks. I'm mostly -1 on this, and I think
the major/minor hack I suggested can solve this use case fairly
cleanly, but I'm open to counter arguments. What might be nice,
however, is to add a padx, pady properties to text instances in
general or maybe just ticklabels in specific, that will shift their
horizontal and vertical position by a fixed amount in points.
JDH