On Mon, Feb 3, 2014 at 12:27 PM, Chris Angelico <ros...@gmail.com> wrote: > On Tue, Feb 4, 2014 at 4:41 AM, Skip Montanaro <s...@pobox.com> wrote: >> I think this means that at configure time, OpenSuSE and our vendor >> chose different values for the --enable-unicode option. Is that >> correct? > > Easy enough to check. Fire up each Python and have a look at what > sys.maxunicode is - if it's 65535, you have a buggy-mode Python that > uses either UCS-2 or UTF-16 internally.
Thanks. I get 65535 for our vendor-built Python, and 1114111 from /usr/bin/python. So (no great surprise), it looks like our vendor is to blame. > But there is another concern, which your second point minorly touches > on. I'm not certain, but I think the name > _PyUnicodeUCS4_AsDefaultEncodedString means that VTK was built against > a wide Python ("UCS4") and calls _PyUnicode_AsDefaultEncodedString. > According to PEP 393, that function - which had always been internal > anyway - is completely removed. Porting VTK to Python 3.3+ will mean > changing that. I'm not concerned about that, certainly not in the immediate term. /usr/bin/python and VTK appear to agree on this stuff. I trust Kitware and the OpenSuSE people to take care of these sorts of problems if VTK ever supports Python 3.x. Skip -- https://mail.python.org/mailman/listinfo/python-list