<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>First, thanks so much for the careful notes and the useful examples!</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">*** supporting non-string values</div><div class=""><br class=""></div><div class="">In the original implementation a cast through numpy was used which</div><div class="">converted all non-string values to strings so things like</div><div class=""><br class=""></div><div class="">#+BEGIN_SRC python</div><div class="">  plt.bar([1, 2, 'apple'], [1, 2, 3])</div><div class=""><br class=""></div><div class="">#+END_SRC</div><div class=""><br class=""></div><div class="">would work.  However this lead to the =2= and ='2'= being treated as</div><div class="">the same (which seems less than great).  Supporting them as different</div><div class="">is possible, but is a fair bit of work because a number of places the</div><div class="">unit framework assumes that 'plain' numbers will pass through</div><div class="">un-changed.</div></div></div></blockquote><div><br class=""></div><div>I don’t think there are *many* places in the unit framework where plain numbers are assumed to be OK to pass through.  </div><div><br class=""></div><div><a href="https://github.com/matplotlib/matplotlib/pull/9776" class="">https://github.com/matplotlib/matplotlib/pull/9776</a></div><div>locks out changing converters, even if the first converter is for floats (I defined a DefaultConverter for numbers).  So you can’t plot a date object on a float axis, or vice versa.  </div><div><br class=""></div><div>It only fails 14 tests where the test tried to pass a hard-coded already-converted value to the axis.  i.e. in some `dates` tests and some `jpl` tests:</div><div><br class=""></div><div>```python</div><div> def test_single_date():<br class="">        time1 = [721964.0]<br class="">        data1 = [-65.54]<br class="">    <br class="">        fig = plt.figure()<br class="">        plt.subplot(211)<br class="">        plt.plot_date(time1, data1, 'o', color='r’)</div><div>```</div><div><br class=""></div><div>But it otherwise passes everything.  I’d need to look at the JPL tests more carefully, but the date tests could easily be rewritten to actually pass date objects if thats the way we want to go.  </div><div><br class=""></div><div>The point is that being able to pass plain numbers after the converter is set is *not* widely *needed*.  The only place I had to change the code was `cla` where the x/y-limits are reset to (0,1) which we didn’t want triggering the converter lock.    However, I can appreciate the argument that it may be *desired* to pass floats.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">A more worrying concern is that</div><div class=""><br class=""></div><div class="">#+BEGIN_SRC python</div><div class="">  x = [52, 32, 'a', 'b']</div><div class="">  y = [0, 1, 2, 3]</div><div class=""><br class=""></div><div class="">  fig, (ax1, ax2) = plt.subplots()</div><div class="">  ax1.plot(x, y, 'o')</div><div class="">  ax2.plot(x[:2], y[:2], 'x')</div><div class=""><br class=""></div><div class="">#+END_SRC</div><div class=""><br class=""></div><div class="">in the first case the ints are treated as categoricals and in the</div><div class="">second they are not.  If we want to support mixed types like this then</div><div class="">we need to make a special class (or use pandas categorical) which does</div><div class="">not have to guess the type on the fly.</div><div class=""><br class=""></div><div class="">requiring if the categorical unit handling is triggered, then all of the values</div><div class="">must be string-like seems like the safest approach.  </div></div></div></blockquote><div><br class=""></div><div>An alternative to locking the converter is just letting the first real call to the axis *set* the converter, and then let the converter to decide if it will deal with arbitrary values.  i.e. the first call above would set the converter to “CategoricalConverter” and the second call would be sent to CategoricalConverter.  Of course calling in the opposite order would send to the DefaultConverter, and it would TypeError on the second call.  </div><div><br class=""></div><div>If we went this route, then the DateConverter could allow plain floats and those would be treated as converted datenums. </div><div><br class=""></div><div>Cheers,   Jody  </div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">*** support for nan</div><div class=""><br class=""></div><div class="">Most of matptollib accepts `np.nan` as 'missing' data which is then</div><div class="">dropped as part of the draw process.  This makes less sense with `bar` but makes</div><div class="">lots of sense with `scatter`.</div><div class=""><br class=""></div><div class="">We should special-case allowing `np.nan` in as a 'string' and map it</div><div class="">map it to it's self.</div><div class=""><br class=""></div><div class="">*** special containers </div><div class=""><br class=""></div><div class="">It was proposed to look for objects arrays as a marker for catagorical</div><div class="">instead of the type of the data.  Do not think we should do this as we try to</div><div class="">be as agnostic about the container as possible everywhere else.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">** appveyor</div><div class=""> - drop building conda package</div><div class=""> - remove conda recipe from the repo</div><div class=""><br class=""></div><div class="">Ryan is taking care of this</div><div class=""><br class=""></div><div class="">** set_theta_grid(frac)</div><div class=""> - merged, improvement over current behavior, raising seems too</div><div class="">   aggressive</div><div class=""><br class=""></div><div class="">** #8947</div><div class=""> - ringing with lots of nans</div><div class=""><br class=""></div><div class="">this is Tom's job to investigate</div><div class=""><br class=""></div><div class="">** talked about traits / traitlets and friends</div><div class=""><br class=""></div><div class="">** major funding</div><div class=""> - get mplot3D 'right'</div><div class="">   - same interface</div><div class="">   - uses real 3D tools</div></div>
_______________________________________________<br class="">Matplotlib-devel mailing list<br class=""><a href="mailto:Matplotlib-devel@python.org" class="">Matplotlib-devel@python.org</a><br class="">https://mail.python.org/mailman/listinfo/matplotlib-devel<br class=""></div></blockquote></div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal;"><div style="word-wrap: break-word;" class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: 'Lucida Sans Typewriter'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;"><div class="">--</div><div class="">Jody Klymak    </div><div class=""><a href="http://web.uvic.ca/~jklymak/" class="">http://web.uvic.ca/~jklymak/</a></div><div class=""><br class="khtml-block-placeholder"></div><div class=""><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></div></span><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>