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.
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]
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.
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?
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?
@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).
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
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!
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 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.
Activity
pelson commented on 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] = vTo
# add british equivs for k, v in list(cnames.items()): if k.find('gray') >= 0: k = k.replace('gray', 'grey') cnames[k] = vOr 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 commented on Oct 15, 2012
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 commented on Oct 15, 2012
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 commented on Oct 16, 2012
Given how far we are through the release cycle, I think that is a sensible idea unless there really are no more 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 commented on Oct 16, 2012
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}")'
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 commented on Oct 16, 2012
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 commented on Oct 16, 2012
*I mean the dictionary error, not the cannot import name mpl error.
goneasync commented on Oct 16, 2012
@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 commented on Jan 25, 2013
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 commented on Jan 29, 2013
Is this bug then resolved? (i.e. git clean -fxd fixes it?)
bfroehle commented on Jan 29, 2013
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 commented on Jan 29, 2013
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.