Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: How to turn a string into a list of integers?
From: Kurt Mueller <kurt.alfred.mueller@gmail.com>
In-Reply-To: <540aa002$0$29968$c3e8da3$5496439d@news.astraweb.com>
Date: Sat, 6 Sep 2014 14:15:26 +0200
Content-Transfer-Encoding: quoted-printable
References: <h2ejdb-mdk.ln1@chris.zbmc.eu> <mailman.13738.1409748804.18130.python-list@python.org> <1amjdb-p3n.ln1@chris.zbmc.eu> <mailman.13776.1409864831.18130.python-list@python.org> <1k9odb-1qs.ln1@chris.zbmc.eu> <mailman.13801.1409939785.18130.python-list@python.org> <540aa002$0$29968$c3e8da3$5496439d@news.astraweb.com>
To: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.13833.1410005730.18130.python-list@python.org>
Lines: 87
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:77650

Am 06.09.2014 um 07:47 schrieb Steven D'Aprano =
<steve+comp.lang.python@pearwood.info>:
> Kurt Mueller wrote:
>> Could someone please explain the following behavior to me:
>> Python 2.7.7, MacOS 10.9 Mavericks

[snip]
Thanks for the detailed explanation. I think I understand a bit better =
now.


Now the part of the two Python builds is still somewhat unclear to me.

> If you could peer under the hood, and see what implementation Python =
uses to
> store that string, you would see something version dependent. In =
Python
> 2.7, you would see an object more or less something vaguely like this:
>=20
> [object header containing various fields]
> [length =3D 2]
> [array of bytes =3D 0x0041 0x00C4]
>=20
>=20
> That's for a so-called "narrow build" of Python. If you have a "wide =
build",
> it will something like this:
>=20
> [object header containing various fields]
> [length =3D 2]
> [array of bytes =3D 0x00000041 0x000000C4]
>=20
> In Python 3.3, "narrow builds" and "wide builds" are gone, and you'll =
have
> something conceptually like this:
>=20
> [object header containing various fields]
> [length =3D 2]
> [tag =3D one byte per character]
> [array of bytes =3D 0x41 0xC4]
>=20
> Some other implementations of Python could use UTF-8 internally:
>=20
> [object header containing various fields]
> [length =3D 2]
> [array of bytes =3D 0x41 0xC3 0x84]
>=20
>=20
> or even something more complex. But the important thing is, regardless =
of
> the internal implementation, Python guarantees that a Unicode string =
is
> treated as a fixed array of code points. Each code point has a value
> between 0 and, not 127, not 255, not 65535, but 1114111.



In Python 2.7:

As I learned from the ord() manual:
If a unicode argument is given and Python was built with UCS2 Unicode,
(I suppose this is the narrow build in your terms),
then the character=92s code point must be in the range [0..65535] =
inclusive;

I understand: In a UCS2 build each character of a Unicode string uses
16 Bits and can represent code points from U-0000..U-FFFF.



=46rom the unichr(i) manual I learn:
The valid range for the argument depends how Python was configured
=96 it may be either UCS2 [0..0xFFFF] or UCS4 [0..0x10FFFF].

I understand: narrow build is UCS2, wide build is UCS4
- In a UCS2 build each character of an Unicode string uses 16 Bits and =
has=20
  code points from U-0000..U-FFFF (0..65535)
- In a UCS4 build each character of an Unicode string uses 32 Bits and =
has=20
  code points from U-00000000..U-0010FFFF (0..1114111)


Am I right?
--=20
Kurt Mueller, kurt.alfred.mueller@gmail.com