8000 MacOSX backend unicode problems in python 3.3 · Issue #1737 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content
MacOSX backend unicode problems in python 3.3 #1737
Closed
@djsutherland

Description

@djsutherland

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."

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0