Menu
▾
▴
matplotlib-devel
|
From: Darren D. <dd...@co...> - 2006-03-21 23:37:10
|
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 |
|
From: John H. <jdh...@ac...> - 2006-03-21 23:54:56
|
>>>>> "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
|
|
From: Darren D. <dd...@co...> - 2006-03-22 14:49:11
|
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 |
|
From: Darren D. <dd...@co...> - 2006-03-22 19:24:12
|
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. |
|
From: Darren D. <dd...@co...> - 2006-03-23 16:58:29
|
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 |
|
From: Jouni K S. <jk...@ik...> - 2006-03-23 19:33:45
|
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
|
|
From: John H. <jdh...@ac...> - 2006-03-30 05:38:57
|
>>>>> "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
|
|
From: Jouni K S. <jk...@ik...> - 2006-03-30 08:45:12
|
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
|
|
From: Darren D. <dd...@co...> - 2006-03-30 11:13:54
|
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').
|
|
From: John H. <jdh...@ac...> - 2006-03-30 15:04:56
|
>>>>> "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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X