nachdem ich noch etwas über surrogate pairs usw. nachgelesen habe, kann ich wohl davon ausgehen, dass das Verhalten von len() so korrekt ist. Allerdings sollte IDLE wohl trotzdem nicht abstürzen. Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...

Hallöchen! Bernd Nawothnig schreibt:

[...]

[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.

Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden. Tschö, Torsten. -- Torsten Bronger Jabber-ID: torsten.bronger@jabber.rwth-aachen.de oder http://bronger-jmp.appspot.com

Bernd Nawothnig schrieb:

On 2012-04-21, Torsten Bronger wrote:

...

...

...

...

[...] oder auf Python 3.3 wechseln, welches es aber leider erst in einer Alpha-Version gibt. Aber dort wird grundsätzlich jedes Unicodezeichen unterstützt und es gibt auch keine Unterscheidung in wide- (32-Bit) und narrow (16 Bit) Builds mehr. Stattdessen wird automatische zur Laufzeit für jeden String die speicherplatzeffizienteste Methode (8, 16 oder 32 Bit) gewählt. Von letzterem wirst Du als Programmierer aber nichts bemerken. Nach außen verhält sich alles genau wie ein 32-Bit wide-build, nur dass es deutlich weniger Speicher benötigt.

Wow, klingt sehr gut. Damit hat man weiteres Kanonenfutter für die UTF-8-vs-UCS-irgendwas-Diskussionen mit Perl-, Lua- und PHP-Freunden.

Das ist für mich *das* neue Feature in Python 3.3. Interessant auch, dass die Laufzeitkosten erstaunlich moderat, eigentlich vernachlässigbar sind. Man gewinnt dadurch nur. Lediglich wird der Laufzeitinterpreter so natürlich ein wenig komplexer, aber ich denke, das ist es Wert.

Und es ist made in Germany - bedank Dich bei Martin von Löwis :-) $ hg log -k "PEP 393" -b default --template "{author}\n" | sort | uniq Antoine Pitrou Ezio Melotti Georg Brandl Martin v. Löwis Victor Stinner Éric Araujo

"made in Germany" trifft es da wohl nicht so ganz. Markus

Und es ist made in Germany - bedank Dich bei Martin von Löwis :-)

Gibt es solch einen Ansatz eigentlich schon in einer anderen Programmiersprache?

In der Form ist mir nichts anderes bekannt; ich halte es also schon für meine Idee (und den Start der Implementierung kommt von Torsten Beckers GSoC-Projekt). Vom Speicherbedarf ist Python damit ungefähr gleichauf mit Perl, was standardmäßig UTF-8 als Unicode-Repräsentation benutzt. "Ungefähr" heißt: In manchen Fällen (z.B. Latin-1, deutsche Umlaute usw.) braucht Python weniger; in anderen Fällen (viel ASCII mit ein paar nicht-Latin-1-Sonderzeichen) braucht Perl weniger (weil im Python-String dann alle Zeichen auf 2 Byte ausgedehnt werden, wenn ein Zeichen 2 Bytes braucht). Der Vorteil der Python-Repräsentation ist m.E., dass der Indexzugriff in konstanter Zeit passiert (was UTF-8 nicht erlaubt). Ciao, Martin

On 2012-04-21, wb wrote:

danke für die Info!

Wobei ich nach einer erhaltenen Mail dazu mein "Made in Germany" noch mal korrigieren wollte. An der Umsetzung waren schon deutlich mehr Personen beteiligt. Also ein reines "Made in Germany" ist das nicht mehr. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]

Am 1. Juni 2012 16:01 schrieb Thomas 'PointedEars' Lahn :

Bernd Nawothnig wrote:

...

On 2012-04-21, wb wrote:

...

Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...

Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.

Wie kommst Du auf dies schmale Brett?  Man kann mit *jeder* Unicode- Codierung *jedes* Unicode-Zeichen darstellen.  Ob UTF-7, UTF-8, UTF-16 oder UTF-32 ist völlig egal.  Die Codierung definiert nur die Länge einer Code- Einheit (und im Fall von UTF-16BE vs. UTF-16LE die Bytereihenfolge), nicht aber die Maximallänge einer Codesequenz und somit auch keinen Maximalwert bezüglich des codierbaren Codepunkts.

UCS 2 kann nur und ausschließlich Zeichen aus der BMP kodieren. Code-Points außerhalb der BMP lassen sich in UCS 2 nicht darstellen. Mithin kann auch ein UCS-2-Build von CPython nur und ausschließlich Zeichen aus der BMP in Zeichenketten verarbeiten.

Michael Ströder wrote:

Thomas 'PointedEars' Lahn wrote:

...

Bernd Nawothnig wrote:

...

On 2012-04-21, wb wrote:

...

Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...

Es ist dann ein UCS-2-Build:

--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)

ACK, das ergibt Sinn.

...

...

Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.

Wie kommst Du auf dies schmale Brett?

Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?

Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen). Das hat aber mit der Zeichencodierung UTF-16 nichts zu tun. Die Bezeichnung "UTF-16 build" ist daher fhcsal. Man könnte es eben höchstens (veraltet) als "UCS-2-Build" bezeichnen, weil UCS-2 eben jene Einschränkungen mit sich brachte, die der Unicode-2.0+-Zeichensatz und UTF-16 nicht mehr haben (AIUI, CMIIW):

So richtig verstehe ich das hier nicht: What is the difference between UCS-2 and UTF-16? http://unicode.org/faq/basic_q.html#14

"[..] Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters."

UCS-2 steht für Universal Character Set-2, eine 2-Byte Codierung für einen Zeichensatz gleichen Namens aus ingesamt *genau* 65536 möglichen Zeichen. Das heisst, eine Codesequenz für die Darstellung eines Zeichens besteht aus *genau* *einer* Code-Einheit von 16 Bit Länge (damit lassen sich genau 65536 verschiedene Zustände darstellen). Bevor das Unicode Consortium im Jahr 1996 "The Unicode Standard" 2.0 (mit "surrogate pairs") und darin unter anderem auch die dazugehörige Codierung UTF-16 entwickelte [2a], gab es bereits per ISO/IEC 10646-1:1993 UCS-2 als Standard für die Codierung (mehr oder weniger) aller Zeichen der (inzwischen so genannten) Basic Multilingual Plane (BMP; U+0000 bis U+FFFF [2b]) und nur genau dieser Zeichen. [2c] Mit UTF-16 werden hingegen Zeichen des *erweiterbaren* Unicode 2.0+- Zeichensatzes [3] codiert (ggf. als Kombination von Zeichen mit verschiedenen Codepunkten). Diese Codierung hat gegenüber der für UCS-2 verwendeten den Vorteil, dass auch Zeichen jenseits der BMP (die in Unicode standardisiert sind) dargestellt werden können. Dazu wird eine zweite Code- Einheit – von ebenfalls 16 Bit Länge – vorangestellt, die angibt, dass die erste und nachfolgende zu einer Codesequenz gehören, d. h. *gemeinsam* den Codepunkt für eine solches Zeichen beschreiben. [4] Die Implementierung muss dies aber unterstützen, sonst kommt Zeichensalat heraus. Andere in Unicode 2.0+ definierte Codierungen, wie etwa UTF-8, haben gegenüber UCS-2 und UTF-16 wiederum den Vorteil, dass für die Darstellung von Zeichen mit niedrigeren Codepunkten ggf. nur 1 Code-Einheit, d. h. bei UTF-8 also 8 Bit, erforderlich ist. Die Datei wird bei gleichem Informationsgehalt also tendenziell kleiner. Dies trifft für alle Zeichen zu, die auch mit US-ASCII codiert werden konnten/können (U+0000 bis U+007F). [5] Gleichzeitig kann man aber mit Surrogatcodes (spezielle Ersatzcodes in einer Codesequenz, deren Wert allein einen mit keinem Zeichen belegten Codepunkt und somit auch kein Zeichen beschreibt) aber auch Zeichen jenseits der BMP (ab U+10000) darstellen und ist somit maximal flexibel (entsprechende Schriftarten zur Anzeige von Glyphen jenseits der BMP, wie etwa antike Schriften – Linear B [6], ägyptische Hieroglyphen [7] etc. –, vorausgesetzt). Einen sehr guten Einblick, wie Unicode funktioniert, erhält man mit den Unicode-Tools von Richard Ishida (W3C, Unicode Editorial Committee) [8a], angefangen mit dem Unicode Code Converter [8b]. Beispielsweise lohnt es sich bereits, etwa ein "ä" in "Mixed input" einzugeben, die "Convert"- Schaltfläche zu aktivieren und sich die Darstellung dieses Zeichens in den verschiedenen Codierungen anzusehen. UniView [8c] bietet dann eine grafische Darstellung der Zeichen und einen Überblick über die Bereiche des Zeichensatzes. (Für Letzteres ebenfalls gut geeignet sind auch die Linux- Programme gucharmap [9a] und KCharSelect [9b], wobei ich ersteres bevorzuge.) ______ [1] http://docs.python.org/library/sys.html#sys.maxunicode [2a] http://en.wikipedia.org/wiki/Unicode#Versions [2b] http://en.wikipedia.org/wiki/Basic_Multilingual_Plane [2c] http://en.wikipedia.org/wiki/UCS-2 [3] http://www.unicode.org/faq/basic_q.html#1 [4] http://www.unicode.org/faq/basic_q.html#13 [5] http://www.unicode.org/faq/utf_bom.html [6] http://rishida.net/scripts/uniview/?codepoints=10000 [7] http://rishida.net/scripts/uniview/?codepoints=13142 [8a] http://www.rishida.net/ [8b] http://www.rishida.net/tools/conversion/ [8c] http://rishida.net/scripts/uniview/ [9a] https://live.gnome.org/Gucharmap [9b] http://utils.kde.org/projects/kcharselect/ -- PointedEars Please do not Cc: me. / Bitte keine Kopien per E-Mail.

On Fri, 1 Jun 2012 16:17:33 +0200 Sebastian Wiesner wrote:

Am 1. Juni 2012 16:01 schrieb Thomas 'PointedEars' Lahn :

...

Bernd Nawothnig wrote:

...

On 2012-04-21, wb wrote:

...

Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...

Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann.

Wie kommst Du auf dies schmale Brett?  Man kann mit *jeder* Unicode- Codierung *jedes* Unicode-Zeichen darstellen.  Ob UTF-7, UTF-8, UTF-16 oder UTF-32 ist völlig egal.  Die Codierung definiert nur die Länge einer Code- Einheit (und im Fall von UTF-16BE vs. UTF-16LE die Bytereihenfolge), nicht aber die Maximallänge einer Codesequenz und somit auch keinen Maximalwert bezüglich des codierbaren Codepunkts.

UCS 2 kann nur und ausschließlich Zeichen aus der BMP kodieren. Code-Points außerhalb der BMP lassen sich in UCS 2 nicht darstellen. Mithin kann auch ein UCS-2-Build von CPython nur und ausschließlich Zeichen aus der BMP in Zeichenketten verarbeiten.

Zu beachten ist dass ab Python 3.3 diese ganze Unterscheidung wegfällt weil PEP 393 einige Veränderungen mit sich bringt. So wie früher unter Windows Python üblicherweise ein UCS-2 Build war verhält es sich nun wie ein UCS-4 Build (wie es in den meisten Linux-Distributionen schon seit langem üblich ist). Siehe What's New In Python 3.3[1]. grüße, Marek [1] http://docs.python.org/dev/whatsnew/3.3.html

Michael Ströder wrote:

Thomas 'PointedEars' Lahn wrote:

...

Michael Ströder wrote:

...

Thomas 'PointedEars' Lahn wrote:

...

Bernd Nawothnig wrote:

...

On 2012-04-21, wb wrote:

...

Laut sys.maxunicode (= 65535) habe ich wohl auch eine UTF-16 build, was genau das heißen mag...

Es ist dann ein UCS-2-Build:

--enable-unicode[=ucs[24]]beinahe Enable Unicode strings (default is ucs2)

ACK, das ergibt Sinn.

...

...

...

Das heißt, dass dann nicht jedes Unicodezeichen intern abgespeichert werden kann, also nicht nur nicht dargestellt werden kann. Wie kommst Du auf dies schmale Brett? Ist sys.maxunicode nicht die max. Anzahl der Unicode Code Points?

Es ist "An integer giving the largest supported code point for a Unicode character." [1], was fast auf dasselbe hinausläuft (die max. Anzahl der dann möglichen Codepunkte ist genau 1 mehr, denn U+0000 wird darin eingeschlossen).

Also hatte Bernd durchaus recht mit der Vermutung, dass bei der betreffenden Python-Installation nicht alle Unicode-Zeichen intern verarbeitet werden können, auch wenn er sich vielleicht bzgl. Unicode-Begrifflichkeiten ungeschickt ausgedrückt haben mag.

Möglicherweise. Da eine Codesequenz mit Surrogat-Codepunkten für Zeichen *jenseits* der BMP auch nur aus den Codes von zwei oder mehr Codepunkten *innerhalb* der BMP besteht, kann man das auch anders interpretieren. Ich frage mich allerdings, wo er den flcsahlen Begriff "UTF-16 build" dafür überhaupt her hat. Aus der Python-Dokumentation offensichtlich nicht, und aus der python-Hilfe offensichtlich auch nicht. Udiags. -- PointedEars Please do not Cc: me. / Bitte keine Kopien per E-Mail.