Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RuntimeError: dictionary changed size during iteration from colors.py, 3.3 but not 3.2 #1401

Closed
goneasync opened this issue Oct 15, 2012 · 12 comments
Milestone

Comments

@goneasync
Copy link

I've been having some problems running matplotlib tests after installing into python3.3 on a Mac OS X 10.7.5. Build went fine, but:

pv-chem-1762:tests jgehman$ ./backend_driver.py
Traceback (most recent call last):
File "./backend_driver.py", line 25, in
import matplotlib.rcsetup as rcsetup
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/init.py", line 151, in
from matplotlib.rcsetup import (defaultParams,
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/rcsetup.py", line 20, in
from matplotlib.colors import is_color_like
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/colors.py", line 205, in
for k, v in cnames.items():
RuntimeError: dictionary changed size during iteration

I thought this might have something to do with a final comma in the dictionary define just above line 205, but deleting this hasn't helped.

The test does run under 3.2, however!

@pelson
Copy link
Member

pelson commented Oct 15, 2012

If your in a position to test, try changing the lines:

# add british equivs
for k, v in cnames.items():
    if k.find('gray') >= 0:
        k = k.replace('gray', 'grey')
        cnames[k] = v

To

# add british equivs
for k, v in list(cnames.items()):
    if k.find('gray') >= 0:
        k = k.replace('gray', 'grey')
        cnames[k] = v

Or even:

# add British equivs
for color_name in list(cnames):
    if 'gray' in color_name:
        brit_colour = color_name.replace('gray', 'grey')
        cnames[brit_color] = cnames[color_name]

Cheers,

@goneasync
Copy link
Author

Yup, either of those work, thanks!

Well, the problem progresses, anyway, to:

pv-chem-1762:tests jgehman$ ./backend_driver.py
Traceback (most recent call last):
File "./backend_driver.py", line 25, in
import matplotlib.rcsetup as rcsetup
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/init.py", line 669, in
class RcParams(dict):
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/init.py", line 679, in RcParams
defaultParams.iteritems() ])
AttributeError: 'dict' object has no attribute 'iteritems'

Not sure this warrants another ticket, as it's easily enough fixed by replacing all 'iteritems' with 'items' and 'iterkeys' with 'keys' in the offending file.

After that, there's lot of ImportErrors, but I have to go to sleep now (East Coast Australia), I'll see if I can sort through the rest tomorrow. Many thanks.

@WeatherGod
Copy link
Member

In light of this revelation, should we cap the python support for v1.2.0 at
python 3.2? I would hate to do that, but I really don't feel good about
trawling through code, making such changes. Also, isn't 2to3 supposed to
take care of most of these issues?

@pelson
Copy link
Member

pelson commented Oct 16, 2012

In light of this revelation, should we cap the python support for v1.2.0 at python 3.2?

Given how far we are through the release cycle, I think that is a sensible idea unless there really are no more issues.

File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/init_.py", line 679, in RcParams
defaultParams.iteritems() ])

Also, isn't 2to3 supposed to take care of most of these issues?

Yes:

$> cat test.py
a = {}
a.iteritems()

$> 2to3 test.py
--- test.py (original)
+++ test.py (refactored)
@@ -1,2 +1,2 @@
 a = {}
-a.iteritems()
+iter(a.items())

@goneasync : How have you built/installed matplotlib? Normally, when using setup.py it will run 2to3 for you (so long as you are not doing a python setup.py build_ext --inplace).

@goneasync
Copy link
Author

Yes, I've build/installed, per my most recent history excerpt (performed after thorough cleans):

682 sudo make -f make.osx PREFIX=/usr/local PYVERSION=3.3 fetch deps &> build33.log
683 make -f make.osx PREFIX=/usr/local PYVERSION=3.3 mpl_build &> build33b.log
684 sudo make -f make.osx PREFIX=/usr/local PYVERSION=3.3 mpl_install &> build33c.log

The build33b.log (the actual mpl_build) has a large block of "Running 2to3..." percentage updates, with no apparent hangups or errors.

There are no other errors, only warnings during build, all of the sort:
#warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION". I haven't yet tried another build with this advice.

I'd edited make.osx, copied into the git cloned directory from a different tar.gz distribution, as follows:
PYVERSION=3.3
MACOSX_DEPLOYMENT_TARGET=10.7
OSX_SDK_VER=10.7

< ${PYTHON} -c 'import urllib; urllib.retrieve("${ZLIBURL}", "${ZLIBFILE}")' &&
< ${PYTHON} -c 'import urllib; urllib.retrieve("${PNGURL}", "${PNGFILE}")' &&\

< ${PYTHON} -c 'import urllib; urllib.retrieve("${FREETYPEURL}", "${FREETYPEFILE}")'

 ${PYTHON} -c 'import urllib.request; urllib.request.urlretrieve("${ZLIBURL}", "${ZLIBFILE}")' &&\
 ${PYTHON} -c 'import urllib.request; urllib.request.urlretrieve("${PNGURL}", "${PNGFILE}")' &&\
 ${PYTHON} -c 'import urllib.request; urllib.request.urlretrieve("${FREETYPEURL}", "${FREETYPEFILE}")'

If it helps to illuminate anything, making the edits by hand (the ones to iteritems and iterkeys that @pelson highlights should have been handled by 2to3), and trying again to run example/tests/backend_driver.py, every module give the following failure at pylab.py:
File "_tmp_annotation_demo2.py", line 9, in ]
from pylab import savefig
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pylab.py", line 1, in
from matplotlib.pylab import *
File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/pylab.py", line 222, in
from matplotlib import mpl # pulls in most modules
ImportError: cannot import name mpl

I admit I'm new to Python, so all I'm working from here is an intuition from 20 years of intermittent hacking in C, Perl, and other odds and ends, as well as reference to the Dusty Phillips book. I've tried a few variations on the import syntax in the matplotlib pylab.py module, to no avail. Taken all together, I suspect I've got something more for fundamental misconfigured on my system, and would be happy to entertain any ideas. Thanks!

@dmcdougall
Copy link
Member

I got this error earlier today on python 3.2. I apparently installed mpl of a python2.7 version of the installation and the python 3.2 interpreter was picking up the compiled byte-code from 2.7. I nuked all my *.pyc files and that fixed everything.

I installed from source, though.

Have you tried that?

@dmcdougall
Copy link
Member

*I mean the dictionary error, not the cannot import name mpl error.

@goneasync
Copy link
Author

@dmcdouball I'll try that -- perhaps there's something in it with the import error as well? Can you run the backend_driver test successfully?

@bfroehle
Copy link
Contributor

I just ran into this (RuntimeError: dictionary changed size during iteration) when building from the 1.2.x git source, but a quick git clean -xfd before building (python3 setup.py build && python3 setup.py install) solved all of my problems.

@mdboom
Copy link
Member

mdboom commented Jan 29, 2013

Is this bug then resolved? (i.e. git clean -fxd fixes it?)

@bfroehle
Copy link
Contributor

As far as I'm concerned, yes. But I wasn't the one who originally reported this. In any case I don't think there is enough here to act on.

@dmcdougall
Copy link
Member

Ok, well then I'll close it for the time being since this appears to be resolved.

@goneasync If it is the case that I have closed this erroneously and you can still reproduce this problem then please feel free to reopen the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants