-
-
Notifications
You must be signed in to change notification settings - Fork 8k
Description
My matplotlib install on Python 3.3.0 seems to be cutting basically all strings in half in the MacOSX backend. This happens with both matplotlib 1.2.0 and the latest git; it doesn't happen on 2.7. I don't have a 3.2 install anymore, but I didn't see this problem with slightly earlier versions of matplotlib.
For example, if I simply run plt.xlabel('xlabel')
, only xla
shows up in the xlabel position. This problem also applies to the ticks, so that labels that would normally say eg 0.2
say just 0.
. In general, it seems that the length of displayed strings is half the length of the passed string, rounded up. If I try to save the resulting figure through the backend, I get this exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.3/site-packages/matplotlib/backends/backend_macosx.py", line 467, in save_figure
self.canvas.get_default_filename())
import matplotlib
ValueError: character U+55002f is not in range [U+0000; U+10ffff]
The Qt4Agg backend seems normal, and matplotlib.test()
succeeds with only known failures and irrelevant warnings.
I'm on OSX 10.8.2 with the most recent Xcode command line tools (clang --version
says Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
); dependencies are installed via homebrew.
The full log of setup.py build
is here, but only this quite suspcious-looking warning stands out:
src/_macosx.m:4979:51: warning: incompatible pointer types passing 'unichar *' (aka 'unsigned short *') to parameter of type
'const Py_UNICODE *' (aka 'const int *') [-Wincompatible-pointer-types]
PyObject* string = PyUnicode_FromUnicode(buffer, n);
^~~~~~
/usr/local/Cellar/python3/3.3.0/Frameworks/Python.framework/Versions/3.3/include/python3.3m/unicodeobject.h:702:23: note: passing argument to
parameter 'u' here
const Py_UNICODE *u, /* Unicode buffer */
^
Since the referenced line is in the function choose_save_file
, it seems like that probably explains at least the problem with saving files, and unichar
being an unsigned short
vs Py_UNICODE
being an int
seems likely to explain the general problem (since a short
is 2 bytes and an int
is 4).
This presumably broke in 3.3 because of something related to PEP 393, which notes that "The Py_UNICODE
type is still supported but deprecated."