AttributeError: can't set attribute ax._hold = self._tmp_hold

[jiaozhh]

Bug report

Bug summary

Basemap cannot work when I update the matplotlib to the new version 3.0.1.

Code for reproduction

import matplotlib.pyplot as plt
import numpy as np
from mpl_toolkits.basemap import Basemap

outfile = r'E:\wrong.tif'

# read in data on lat/lon grid.
# data from https://github.com/matplotlib/basemap/tree/master/examples
hgt = np.loadtxt(r'E:\tmp\basemap\500hgtdata.gz')
lons = np.loadtxt(r'E:\tmp\basemap\500hgtlons.gz')
lats = np.loadtxt(r'E:\tmp\basemap\500hgtlats.gz')
lons, lats = np.meshgrid(lons, lats)

mnh = Basemap(lon_0=-105, boundinglat=20.,
              resolution='c', area_thresh=10000., projection='nplaea')
xnh, ynh = mnh(lons, lats)
CS = mnh.contour(xnh, ynh, hgt, 15, linewidths=0.5, colors='k')
CS = mnh.contourf(xnh, ynh, hgt, 15, cmap=plt.cm.Spectral)

mnh.drawcoastlines(linewidth=0.5)
delat = 30.
circles = np.arange(0., 90., delat).tolist() + \
          np.arange(-delat, -90, -delat).tolist()
mnh.drawparallels(circles, labels=[1, 0, 0, 0])
delon = 45.
meridians = np.arange(0, 360, delon)
mnh.drawmeridians(meridians, labels=[1, 0, 0, 1])
plt.title('NH 500 hPa Height (cm.Spectral)')

# colorbar on bottom.
mnh.colorbar(pad='5%')
plt.savefig(outfile, dpi=300, bbox_inches='tight')  
plt.show()

Actual outcome

# If applicable, paste the console output here

Traceback (most recent call last):
  File "E:/MyWork/code/python/psta/tmp.py", line 20, in <module>
    CS = mnh.contour(xnh, ynh, hgt, 15, linewidths=0.5, colors='k')
  File "D:\Python36\lib\site-packages\mpl_toolkits\basemap\__init__.py", line 542, in with_transform
    return plotfunc(self,x,y,data,*args,**kwargs)
  File "D:\Python36\lib\site-packages\mpl_toolkits\basemap\__init__.py", line 3566, in contour
    self._restore_hold(ax)
  File "D:\Python36\lib\site-packages\mpl_toolkits\basemap\__init__.py", line 3229, in _restore_hold
    ax._hold = self._tmp_hold
AttributeError: can't set attribute

Expected outcome

Matplotlib version

• Operating system: Windows 10 x64
• Matplotlib version: 3.0.1
• Matplotlib backend (print(matplotlib.get_backend())): module://backend_interagg
• Python version: 3.6.6
• Jupyter version (if applicable): None
• basemap version: 1.2.0
• PyCharm version: 2018.2.4

I install matplotlib and basemap from https://www.lfd.uci.edu/~gohlke/pythonlibs.

[make-ing]

same here! since the update to matplotlib 3.0.1 I get the exact same error as above.

[tacaswell]

in mpl3.0.0 we removed the entire 'hold' mechanism, that broke cartopy because they were reading _hold, so for 3.0.1 we put in as a read-only attribute which breaks basemap who is trying to set it! Does basemap work with 3.0.0 (as the variable name suggests the hold value is being stashed.

[WeatherGod]

Basemap works for 3.0.0 and was prepared for the removal of the hold mechanism by checking for the existence of the attribute

…

On Fri, Oct 26, 2018 at 9:06 AM Thomas A Caswell ***@***.***> wrote: in mpl3.0.0 we removed the entire 'hold' mechanism, that broke cartopy because they were reading _hold, so for 3.0.1 we put in as a read-only attribute which breaks basemap who is trying to set it! Does basemap work with 3.0.0 (as the variable name suggests the hold value is being stashed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#435 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARy-AKF-QX6cFjlctQstmLfwCy-Ki5Fks5uowjegaJpZM4X7mew> .

[WeatherGod]

Note, this is why I pointed devs to basemap's PRs for this compatibility shim in the hope that cartopy would adopt that approach. Instead, it was deemed more important to change matplotlib rather than update cartopy in a manner than is backwards compatible.

…

On Fri, Oct 26, 2018 at 9:48 AM Benjamin Root ***@***.***> wrote: Basemap works for 3.0.0 and was prepared for the removal of the hold mechanism by checking for the existence of the attribute On Fri, Oct 26, 2018 at 9:06 AM Thomas A Caswell ***@***.***> wrote: > in mpl3.0.0 we removed the entire 'hold' mechanism, that broke cartopy > because they were reading _hold, so for 3.0.1 we put in as a read-only > attribute which breaks basemap who is trying to set it! Does basemap work > with 3.0.0 (as the variable name suggests the hold value is being stashed. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#435 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AARy-AKF-QX6cFjlctQstmLfwCy-Ki5Fks5uowjegaJpZM4X7mew> > . >

[tacaswell]

sigh, we were trying to unbreak all un-released versions of cartopy.

We were planning to do a release next weekend anyway....

[megies]

Ah, just stumbled over this one in our CI as well, but I see it is on the radar already.. thanks in advance for fixing. 👍

[scollis]

I'm confused @WeatherGod : Does this mean we can only use Basemap with MPL 3.0.0 ?
This is breaking our unit testing.. We are in the middle of moving to Cartopy.

[WeatherGod]

It means that matplotlib v3.0.1 is incompatible with basemap v1.1.x. You can either use a different version of matplotlib, or an earlier version of basemap.

basemap v1.1.x introduced a backwards-compatible shim to prepare for the upcoming changes in matplotlib v3.0.0, which worked, but cartopy wasn't ready for it. So, matplotlib v3.0.1 tried to fix things for cartopy, but ended up breaking things for basemap. matplotlib v3.0.2 will fix things for everybody while cartopy prepares to put out a new release that should work for all versions of matplotlib.

[scollis]

Thanks.. I am giving a course next week and need to make some decisions. Any idea how close MPL 3.0.2 is?
Huge thanks @WeatherGod for all your work in this.. Yet another wake up call for us to move on NOW

[jamessong]

I have 3.0.1 and basemap 1.1.0, the problem is still there

[jamessong]

I have to say that python has a bad reputation with these ill-managed packages - that is probably the shortcomings of anaconda - R studio never had these issues. I hope python will gradually die and give in to R

[scollis]

This is a issue tracker not for chat please stop posting here

…

Sent from my iPad

On Nov 25, 2018, at 8:32 PM, jamessong ***@***.***> wrote: I have to say that python has a bad reputation with these ill-managed packages - that is probably the shortcomings of anaconda - R studio never had these issues. I hope python will gradually die and give in to R — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[WeatherGod]

@jamessong, as I have noted, this issue is specifically the combination of matplotlib v3.0.1 and basemap v1.1.x. This is not a packaging issue. Matplotlib partly introduced a compatibility shim after a feature was removed in v3.0.0 that broke cartopy. That compatibility shim broke basemap. The matplotlib v3.0.2 fixes everything, which is why this issue is now closed.

[saangaa]

Same here and after I updated matplotlib 3.0.1 to 3.0.2, the problem was solved.

[megies]

@jamessong: I have to say that python has a bad reputation with these ill-managed packages - that is probably the shortcomings of anaconda - R studio never had these issues. I hope python will gradually die and give in to R

@WeatherGod I am so very jealous of your unfathomable patience and composure. Even simply considering to answer to something like this is rather heroic.

@jamessong I would not wish being responsible for giving customer support to you on whatever matter on my worst enemies. The problem and workaround is described very concise in the very last post (at the time of your first post) and yet you decide to come up with a post brimming with misconceptions and rude accusations towards the people that put their spare time into maintaining awesome projects like matplotlib, basemap or Anaconda (through conda-forge).
I am so very, very glad I don't understand your mindset.
Please just stop using Python if you think it's a bad thing and stop molesting people that make Python great, won't you?

[hxd1011]

Same here and after I updated matplotlib 3.0.1 to 3.0.2, the problem was solved.

this really fixed my problem!

[megies]

@QuLogic just FYI this affects fedora 31, see skipped tests in http://tests.obspy.org/108832/