[issue4678] Unicode: multiple chars for high code points

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2008-12-17 00:53, Martin v. Löwis wrote:
> Martin v. Löwis  added the comment:
> 
> As Marc-Andre say, this is not a bug. Finding out the exact name of the
> configure option is left as an exercise.

Ah, so that changed as well... for Python 3.0 it's called
--with-wide-unicode.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4678] Unicode: multiple chars for high code points

[Martin v. Löwis]

Martin v. Löwis  added the comment:

As Mark-Andre say, this is not a bug. Finding out the exact name of the
configure option is left as an exercise.

--
nosy: +loewis
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4678] Unicode: multiple chars for high code points

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2008-12-17 00:25, Eric Eisner wrote:
> New submission from Eric Eisner :
> 
> I discovered this when trying to splice a string containing unicode
> codepoints higher than U+
> 
> 
> all examples on 32-bit Ubuntu Linux
> 
> python 2.5.2 (for comparison):
> sys.maxunicode # 1114111
> len(unichr(66674)) # 1
> len(u'\U00010472') # 1
> len(u'𐑲')  # 2
> unichr(66674)[0]   # u'\U00010472'
> 
> 
> python 3.0: (same behavior on ubuntu's rc1 package and my build(r67781)
> from svn)
> sys.maxunicode# 65535
> len(chr(66674))   # 2
> len('\U00010472') # 2
> len('𐑲')  # 2
> chr(66674)[0] # '\ud801'
> 
> I expect the nth element of a string to be the nth codepoint, regardless
> of unicode settings. I don't know why the maxunicode is configured
> differently (both compiled by ubuntu), but is this the expected behavior?
> 
> If this is actually the expected behavior, how can I configure a build
> of python to use the larger maxunicode value?

You are seeing the different behavior because you've probably
built Python 3.0 from source and used the Ubuntu default Python
install for comparison:

The default Python 3.0 build will create a UCS2 unless you specify
the --enable-unicode=ucs4 configure option.

The Ubuntu Python build (like many other Linux distros) uses this
option per default.

--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4678] Unicode: multiple chars for high code points

[Eric Eisner]

New submission from Eric Eisner :

I discovered this when trying to splice a string containing unicode
codepoints higher than U+


all examples on 32-bit Ubuntu Linux

python 2.5.2 (for comparison):
sys.maxunicode # 1114111
len(unichr(66674)) # 1
len(u'\U00010472') # 1
len(u'𐑲')  # 2
unichr(66674)[0]   # u'\U00010472'


python 3.0: (same behavior on ubuntu's rc1 package and my build(r67781)
from svn)
sys.maxunicode# 65535
len(chr(66674))   # 2
len('\U00010472') # 2
len('𐑲')  # 2
chr(66674)[0] # '\ud801'

I expect the nth element of a string to be the nth codepoint, regardless
of unicode settings. I don't know why the maxunicode is configured
differently (both compiled by ubuntu), but is this the expected behavior?

If this is actually the expected behavior, how can I configure a build
of python to use the larger maxunicode value?

--
components: Unicode
messages: 77940
nosy: ede
severity: normal
status: open
title: Unicode: multiple chars for high code points
versions: Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com