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. > If so, I have a few questions: > > 1. Is there a workaround short of rebuild one version of Python or the other? I don't think so. What you're seeing may be a relatively simple-looking error, but the internal representation of every single string is different. Bound to cause problems. > 2. Does the flexible string representation avoid this problem? Well yes, by eliminating the option of a UCS-2 build altogether, the FSR prevents the compatibility problem of some choosing it and some not :) > 3. Which builder (OpenSuSE or our vendor) decided the default wasn't > good enough? Not sure, but I would strongly recommend going for a wide build. It may be a pain to use that much RAM everywhere, but at least you get correct behaviour; and that's how most Pythons on Linux have been (most Windows Pythons were built narrow). 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list