Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #65364 > unrolled thread

Re: undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString Skip Montanaro <skip@pobox.com> - 2014-02-03 12:59 -0600

#65364 — Re: undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString

On Mon, Feb 3, 2014 at 12:27 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Feb 4, 2014 at 4:41 AM, Skip Montanaro <skip@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

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web