matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
[...]
> 
> How about markup="TeX" then?

"markup" is a good kwarg for this; it is descriptive and won't be 
confused with anything else.


Eric

> 
>> And yes, having a rcoption default seems like it could be handy.
> 

Hi,

  I wonder if there is any example to copy a line belong to one figure 
to another figure?

Thanks
Xuedong

On Thursday 02 August 2007 11:03:09 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> >> On 8/2/07, Michael Droettboom <md...@st...> wrote:
> >>> I don't know if we ever reached consensus on how to specify math text
> >>> vs. regular text.  I agree with Eric that it's down to two options:
> >>> using a new kw argument (probably format="math" to be most
> >>> future-proof) or Math('string').  I don't think I have enough
> >>> "historical perspective" to really make the call but I do have a
> >>> concern about the second option that it may be confusing depending on
> >>> how "Math" is imported.  (It may have to be pylab.Math in some
> >>> instances but not in others.)  But I don't have a strong objection.
> >>>
> >>> Any last objections to going with the new keyword argument?
> >>
> >> I'm +1 on the kwarg approach -- it seems most consistent with our other
> >> usage.
> >
> > Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it
> > would be appropriate to have the kwarg default to None, and if None
> > reference an rcoption like text.texformatting? That might be the least
> > disruptive all around.
>
> I think format="TeX" may be a bit misleading, since it uses something
> TeX-like, but not really TeX (as the usetex stuff does).  That said, I
> don't really have a better suggestion ;)
>
> The idea also is that in the future this could support other values,
> e.g. format="html" might support "<b>bold</b>" for instance, so
> texformatting=True would be less extensible overall.

How about markup="TeX" then?

> And yes, having a rcoption default seems like it could be handy.

Darren Dale wrote:
> On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
>   
>> On 8/2/07, Michael Droettboom <md...@st...> wrote:
>>     
>>> I don't know if we ever reached consensus on how to specify math text
>>> vs. regular text.  I agree with Eric that it's down to two options:
>>> using a new kw argument (probably format="math" to be most future-proof)
>>> or Math('string').  I don't think I have enough "historical perspective"
>>> to really make the call but I do have a concern about the second option
>>> that it may be confusing depending on how "Math" is imported.  (It may
>>> have to be pylab.Math in some instances but not in others.)  But I don't
>>> have a strong objection.
>>>
>>> Any last objections to going with the new keyword argument?
>>>       
>> I'm +1 on the kwarg approach -- it seems most consistent with our other
>> usage.
>>     
>
> Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
> would be appropriate to have the kwarg default to None, and if None reference 
> an rcoption like text.texformatting? That might be the least disruptive all 
> around.
>   
I think format="TeX" may be a bit misleading, since it uses something 
TeX-like, but not really TeX (as the usetex stuff does).  That said, I 
don't really have a better suggestion ;)

The idea also is that in the future this could support other values, 
e.g. format="html" might support "<b>bold</b>" for instance, so 
texformatting=True would be less extensible overall.

And yes, having a rcoption default seems like it could be handy.

Cheers,
Mike

On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> On 8/2/07, Michael Droettboom <md...@st...> wrote:
> > I don't know if we ever reached consensus on how to specify math text
> > vs. regular text.  I agree with Eric that it's down to two options:
> > using a new kw argument (probably format="math" to be most future-proof)
> > or Math('string').  I don't think I have enough "historical perspective"
> > to really make the call but I do have a concern about the second option
> > that it may be confusing depending on how "Math" is imported.  (It may
> > have to be pylab.Math in some instances but not in others.)  But I don't
> > have a strong objection.
> >
> > Any last objections to going with the new keyword argument?
>
> I'm +1 on the kwarg approach -- it seems most consistent with our other
> usage.

Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
would be appropriate to have the kwarg default to None, and if None reference 
an rcoption like text.texformatting? That might be the least disruptive all 
around.

Darren

On 8/2/07, Michael Droettboom <md...@st...> wrote:
> I don't know if we ever reached consensus on how to specify math text
> vs. regular text.  I agree with Eric that it's down to two options:
> using a new kw argument (probably format="math" to be most future-proof)
> or Math('string').  I don't think I have enough "historical perspective"
> to really make the call but I do have a concern about the second option
> that it may be confusing depending on how "Math" is imported.  (It may
> have to be pylab.Math in some instances but not in others.)  But I don't
> have a strong objection.
>
> Any last objections to going with the new keyword argument?

I'm +1 on the kwarg approach -- it seems most consistent with our other usage.

I don't know if we ever reached consensus on how to specify math text 
vs. regular text.  I agree with Eric that it's down to two options: 
using a new kw argument (probably format="math" to be most future-proof) 
or Math('string').  I don't think I have enough "historical perspective" 
to really make the call but I do have a concern about the second option 
that it may be confusing depending on how "Math" is imported.  (It may 
have to be pylab.Math in some instances but not in others.)  But I don't 
have a strong objection.

Any last objections to going with the new keyword argument?

Cheers,
Mike

Eric Firing wrote:
> That leaves some variant of 2 [a keyword argument] and the Math('string') idea.  I find the 
> latter quite pythonic; it is a very concise, readable, and general way 
> of attaching extra information to a string object, and it does not 
> require passing yet another kwarg through a sequence of function and 
> method calls.  But if it is judged to be too out-of-character with the 
> rest of the mpl api, or if in practice it would cause trouble that I 
> don't see yet, then I am happy to let it go.  I have not thought it 
> through carefully, and I am not attached to it.
>
> If a variant of 2 is chosen, one might shorten the kwarg to "math".  Or 
> use "format='math'" or something like that.  This is more flexible than 
> a boolean kwarg, leaving the door open to additional options for 
> interpretation of strings--but not quite as flexible and powerful as the 
> math('string') idea.
>