On Mon, Mar 1, 2010 at 8:36 AM, Michael Droettboom <md...@stsci.edu> wrote:
> Alan G Isaac wrote:
> >> Gökhan Sever wrote:
> >>
> >>> For the second idea you mean something as generic as plotting such
> >>> markers?
> >>> plt.plot(range(10), linestyle='None', marker=u'※ ')
> >>>
> >
> >
> > On 3/1/2010 8:33 AM, Michael Droettboom wrote:
> >
> >> Yes -- but it can't be quite this simple, since there is already a set
> >> of strings that have specific meanings for markers, and we wouldn't
> want
> >> to change that behavior. In order to use an arbitrary character or
> >> string, we'd need additional syntax to indicate that's what you want to
> >> do.
> >>
> >
> >
> > Perhaps naively, I do not see why.
> > A small number of strings have predefined meanings.
> > Just keep documenting that and then test if the
> > provided string is in this set.
> > Otherwise, use the provided string.
> > This seems very nice.
> >
> > If that is too implicit, then adding a markerstr keyword argument
> > seems the right way to go. It would override the marker argument,
> > and any string could be used, getting rid of the above problem.
> >
> > Cheers,
> > Alan Isaac
> > (just a user)
> >
> What if you want to use the letter 'o' as a marker? That to me seems
> like a potential source of confusion, as well as a little bit limiting.
> What would the escaping syntax be to use the letter 'o'?
>
> As you suggest, adding an additional kwarg is also a way forward. In
> that case, though, I would suggest that providing both a marker and
> markerstr argument should raise an exception. Having implicit
> overriding rules can often lead to confusion.
>
> One downside of the additional kwarg is that you occasionally see code
> like this:
>
> markers = ['o', '.', 'h', 'x']
> for data, marker in zip(datasets, markers):
> plot(data, marker=marker)
>
> If one wanted to mix built-in with non-built-in markers that idiom would
> become much more complex. That's why I proposed sticking to a purely
> string representation -- I'm just not sure of the best or most obvious one.
>
To me it seems like having only one keyword "marker" is easier for the sake
of simplicity as you have already demonstrated with an example. (Having one
keyword to handle all special markers, unicode symbols and strings.) However
probably this will need more coding to handle all the cases properly.
>
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
--
Gökhan
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
