John Hunter wrote:
> On 7/26/07, Darren Dale <[EMAIL PROTECTED]> wrote:
>>> where Math is a wrapper object that signals to "text" that its contents
>>> are to be passed to the mathtext interpreter.
>> I would like to voice my opinion against this idea. I think the backward
>> imcompatibility will be rare, and does not justify the additionaly complexity
>> of the far more common need to interpret mathtext.
>
> I'm on the fence as to how to handle this case. The majority of our
> users will think of $ as the US currency symbol, and will have never
> heard of TeX. Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
> Option 3 is to try and be clever, and interpret an even number of
> unquoted dollar symbols as mathtext, or any string that has a quoted
> dollar sign symbol as mathtext, else assume plain text. Option 4 is
> to treat *all* strings as mathtext, but I think we would pay a pretty
> big performance hit to invoke the mathtext machinery for every piece
> of text. But it is an option. In option 4, of course, users would be
> required to quote all dollar signs, so it is related to option 1 but
> slightly different in how it treats strings with no dollar signs.
>
> I'm not too keen on the text(x, y, Math('string')) proposal, which is
> a little outside the normal matplotlib approach.
>
> Michael, do you have a preference or an alternate proposal?
> JDH
Let's rule out option 3 completely; it is an example of the type of
cleverness that ends up causing more trouble and confusion than it is worth.
I also oppose using something other than the $ to delimit math, if
delimiters are needed, which I think they are. At least in *Tex, a
string of characters (a word) is rendered very differently depending on
whether it is inside an equation or outside.
I suspect that options 1 and 4 will cause endless questions to
matplotlib-users, and grumbling among people in the business and
financial community who use lots of dollar signs and no math.
That leaves some variant of 2 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.
Eric
-------------------------------------------------------------------------
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
