Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On 8/2/07, Michael Droettboom <[EMAIL PROTECTED]> 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.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> On 8/2/07, Michael Droettboom <[EMAIL PROTECTED]> 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
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
Darren Dale wrote:
> On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
>
>> On 8/2/07, Michael Droettboom <[EMAIL PROTECTED]> 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 "bold" for instance, so
texformatting=True would be less extensible overall.
And yes, having a rcoption default seems like it could be handy.
Cheers,
Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
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.
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] copy a line from one figure to another
Hi, I wonder if there is any example to copy a line belong to one figure to another figure? Thanks Xuedong - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
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 <[EMAIL PROTECTED]> 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 "bold" 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.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Mathtext improvements (merging into trunk)
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. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
