COMPAT: matplotlib v0.15rc1 issues #11111
Comments
jreback
added
Visualization
|
attn @WeatherGod Some if not most of this should be handled on our end. |
|
Although, some if this looks like you are reaching in and touching mpl guts in ways that you probably should not be. |
|
@tacaswell let us know which ones those are if you can. I can put in some fixups before we release 0.17. |
|
Also, could you share your linux conda recipe? I can build and upload an OSX version. |
|
fyi, you can easily make this install on travis, e.g. add: right before here this will add to all builds that don't explicity specify things. |
|
We probably should fix the very first one ( As for the color cycle issue... sigh... I don't know how we should address this. cycling completely changed in 1.5, and I relied on the fact that the internal implementation was private in order to do it. I appreciate the fact that older versions of pandas will be completely incompatible with matplotlib v1.5, but even if I were to jury-rig |
|
I don't think you should have to mess up matpltolib's code base just because a downstream library made some bad choices (even one as big as pandas). Thinking through the options on the pandas... we can detect the matplotlib version and work around the cycling changes. I'll look through how much work that will be tonight. My first priority is to get pandas 0.17+ and matplotlib 1.5+ working together correctly. |
|
just make sure you use |
|
Will do! |
|
Sorry I didn't get to come back around to this tonight, please ping me or @WeatherGod (sorry for volunteering you Ben) if you have any questions! |
|
I do have one question. Is there a way to know where in a (color) cycle an axes is at? The use case here is, given an In [13]: df = pd.DataFrame(np.random.randn(10, 2))
In [14]: ax = df[[0]].plot(ax=ax)
In [15]: plt.close()
In [16]: fig, ax = plt.subplots()
In [17]: df[[0]].plot(ax=ax)
Out[17]: <matplotlib.axes._subplots.AxesSubplot at 0x115c4d198>
In [18]: df[[1]].plot(ax=ax, secondary_y=True)
Out[18]: <matplotlib.axes._subplots.AxesSubplot at 0x115b3e978>More specifically, we need a way to answer "if I'm at this color, what's the next color in the user's cycle?". |
|
Sounds like a use for tee(), but there is currently no way to access the We might be able to get away with tee()-ing the private iterators ourselves
|
|
My current, not well-thought out approach is the get the last color used on the original axis, cycler thru cyl = plt.rcParams['axes.prop_cycle']
last = orig_ax.lines()[-1].get_color()
try:
offset = [v['color'] for v in cyl].index(last) + 1
cyl = cyl[offset:]
except ValueError:
passNo idea if it will work yet. This is made more difficult by how we implement |
|
Hmm that won't work since cycles can have repeat colors. |
|
@WeatherGod I don't think we want |
|
So, it still involves touching our internals, but fig, ax = plt.subplots()
ax2 = ax.twinx()
ax2._get_lines = ax._get_lines
ax2._get_patches_for_fill = ax._get_patches_for_fillIf this actually solves the problem we can add a method |
|
@tacaswell thanks, that fixed that class of error. Having some way to share cyclers between multiple axes (probably on the same fig) does seem useful, at lest for this specific case. If you do end up implementing a public way of doing this let me know and I'll replace this code. |
|
@tacaswell seeing this warning MatplotlibDeprecationWarning: This has been deprecated in mpl 1.5, please use the
axes property. A removal date has not been set.quite a bit. I'll make this switches to use |
|
Yes please re axes issue |
Raised at matplotlib/matplotlib#5089 |
|
@tacaswell not sure how you want to handle the failure in import numpy as np
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
ax.errorbar(np.arange(12), np.arange(12), yerr=['zzz'] * 12)As of matplotlib 1.4.3 that raised a TypeError when we subtracted an int from a str. In 1.5 that's a It does seem somewhat strange that the above raises a TypeError, while |
|
I also did a quick search for us doing stuff with non-public methods. Didn't find any more of those, but we do occasionally attach extra data to
sorry 😰 perhaps we should prefix all these with a pandas prefix |
|
Our failure in import numpy as np
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
x = np.arange(4)
y0 = np.zeros(4)
y1 = np.arange(4)
ax.plot(x, y1, label='a')
ax.fill_between(x, y0, y1, label='a')
print(ax.get_legend_handle_labels())on mpl 1.43 this is and with 1.5 it's both If that's an intended change I'll just amend our test. EDIT: Seems like this is the change: http://matplotlib.org/devdocs/users/whats_new.html#support-for-legend-for-polycollection-and-stackplot |
|
The failures from ones like |
|
How are you installing mpl? We just switched to using versioneer and apparently still have some kinks to work out. |
|
Cloned repo, checked out the 1.5rc tag, and built with |
|
attn @pelson re versioneer issues |
|
OK, a PR is coming shortly. Here are the source of the failures / errors
1-3 I've altered the tests to either find / check for the correct thign. EDIT: nevermind on the last one. That was under a block checking if matplotlib was >= 1.3.1, which failed cause the versioneer problems. |
|
5 was intentional, you have an open issue about it where I volunteered to fix it and never got to it... #9161 I think 2 should be investigated on the mpl side and the old behavior restored, or at least always raise the same exception. 3 was intentional. |
I've actually been working to get the matplotlib rc building automatically on OSX, Liunx and Windows using conda with some success (there are still some holes in the build matrix though). It might be a nice way to have easy building of Pandas' release candidate as well. Pretty early days, but take a look at : https://github.com/conda-forge/staged-recipes/tree/matplotlib_partly/recipes
Strange, this works for me: Are you getting the version correctly in the header? If so, we are missing a step elsewhere. If not, what is your version of git? |
|
so we're good there. Git version 2.5.2; I don't have time to dig into it now, but here's what versioneer sees, In [51]: git_versions_from_keywords(get_keywords(), cfg.tag_prefix, True)
keywords are unexpanded, not using
---------------------------------------------------------------------------So it moves on to In [52]: root = os.path.realpath("lib/matplotlib/_version.py")
In [53]: for i in cfg.versionfile_source.split('/'):
....: root = os.path.dirname(root)
....:
In [54]: root
Out[54]: '/Users/tom.augspurger/Envs/dev/lib/python3.4/site-packages/matplotlib'
In [55]: git_pieces_from_vcs(cfg.tag_prefix, root, verbose)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
<ipython-input-55-051801b9ad10> in <module>()
----> 1 git_pieces_from_vcs(cfg.tag_prefix, root, verbose)
NameError: name 'verbose' is not defined
In [56]: git_pieces_from_vcs(cfg.tag_prefix, root, True)
Out[56]:
{'closest-tag': '1.5.0rc1',
'dirty': False,
'distance': 0,
'error': None,
'long': 'ab00a04759f5460f4d2176430594ec194d6f624b',
'short': 'ab00a04'}
In [57]: render(git_pieces_from_vcs(cfg.tag_prefix, root, True), cfg.style)
Out[57]:
{'dirty': False,
'error': None,
'full-revisionid': 'ab00a04759f5460f4d2176430594ec194d6f624b',
'version': '1.5.0rc1'}which seems to be correct, but In [58]: matplotlib.__version__
Out[58]: '0+unknown' |
|
Thinking out loud here a bit. My remaining failure is coming from our time series plotting. We set an attribute I know I said earlier that matplotlib shouldn't have to muck up it's code because pandas wasn't doing things properly. But I might ask for a special case here. The reason (at least a reason) we go through all this is to support interactively plotting multiple timeseries, possibly of different frequency. We need some way to communicate the frequency to the newly plotted timeseries, in case it has to be resampled to the original timeseries' frequency. I'm not sure there's a way to do that without attaching some information to the axes. The strange thing is that this only fails when we |
|
Should have seen this last night. When we ax2 = ax.twinx()
ax2._get_lines = ax._get_lines
@tacaswell working on a smaller example, but in |
|
On the last failure, where before we got back numpy masked array: low = tm.makeTimeSeries()
low[5:25] = np.nan
ax = low.plot()
lines = ax.get_lines()
l = lines[0]
data = l.get_xydata()
tm.assertIsInstance(data, np.ma.core.MaskedArray)
mask = data.mask
self.assertTrue(mask[5:25, 1].all())
So I think this is a change in matplotlib. I should say that visually things are identical. But for now I"m just going to change our tests. |
|
That is a change on our side, we are moving towards arrays filled with |
|
We explicitly tested for it, but it's not actually relied upon anywhere (AFAIK), so it shouldn't be a problem. |
|
@tacaswell sorry, one more MPL change that I missed. This is when you import numpy as np
import matplotlib.pyplot as plt
import matplotlib
x = y = np.arange(4)
c = 'b'
color = 'green'h
fig, ax = plt.subplots()
sc = ax.scatter(x, y, c=c, color=color)
print(matplotlib.__version__, sc.get_facecolor()[0]) |
|
The scatter change is from matplotlib/matplotlib#4079 |
|
@tacaswell didn't someone put up windows builds on conda-forge? (nothing there now, but I recall the discussion). or are they a different channel? |
|
|
There are only win 32 builds |
|
aha! can someone put up the -64 ones? |
Yes. I need to fix a bug, but watch this space. |
|
Not sure how much the logs are visible, but the build is under way: https://ci.appveyor.com/project/pelson/staged-recipes/build/1.0.24 |
|
@pelson awesome! thanks! |
Ahh, a couple of compiler issues for win64. I'll try to track them down in conda-forge/staged-recipes#7. Sadly, I wont be able to do that for ~14 hours. |
|
@pelson no prob. ping when you are ready. I just want to test our pandas fixes for the rc1 on windows. |
install via:
conda install matplotlib -c tacaswell(only linux-64 ATM)this is with
pandas-0.17rc1cc @TomAugspurger @sinhrks @jorisvandenbossche
cc @tacaswell
The text was updated successfully, but these errors were encountered: