Zusammenfassung

Dieser PEP schlägt eine Literal-Syntax für die in PEP 358 eingeführten bytes-Objekte vor. Ziel ist es, eine bequeme Möglichkeit zur Darstellung von ASCII-Strings und beliebigen Binärdaten zu bieten.

Motivation

Bestehende Darstellungen eines ASCII-Strings in Python 3000 umfassen

bytes('Hello world', 'ascii')
'Hello world'.encode('ascii')

Die vorgeschlagene Syntax ist

b'Hello world'

Bestehende Darstellungen einer 8-Bit-Binärsequenz in Python 3000 umfassen

bytes([0x7f, 0x45, 0x4c, 0x46, 0x01, 0x01, 0x01, 0x00])
bytes('\x7fELF\x01\x01\x01\0', 'latin-1')
'7f454c4601010100'.decode('hex')

Die vorgeschlagene Syntax ist

b'\x7f\x45\x4c\x46\x01\x01\x01\x00'
b'\x7fELF\x01\x01\x01\0'

In beiden Fällen sind die Vorteile der neuen Syntax Kürze, ein kleiner Effizienzgewinn und die Erkennung von Kodierungsfehlern zur Kompilierzeit statt zur Laufzeit. Der Vorteil der Kürze macht sich besonders bei der Verwendung von stringähnlichen Methoden von Bytes-Objekten bemerkbar.

lines = bdata.split(bytes('\n', 'ascii'))  # existing syntax
lines = bdata.split(b'\n')  # proposed syntax

Und bei der Konvertierung von Code von Python 2.x zu Python 3000

sok.send('EXIT\r\n')  # Python 2.x
sok.send('EXIT\r\n'.encode('ascii'))  # Python 3000 existing
sok.send(b'EXIT\r\n')  # proposed

Grammatikänderungen

Die vorgeschlagene Syntax ist eine Erweiterung der bestehenden String-Syntax [1].

Die neue Syntax für Strings, einschließlich des neuen Bytes-Literals, ist

stringliteral: [stringprefix] (shortstring | longstring)
stringprefix: "b" | "r" | "br" | "B" | "R" | "BR" | "Br" | "bR"
shortstring: "'" shortstringitem* "'" | '"' shortstringitem* '"'
longstring: "'''" longstringitem* "'''" | '"""' longstringitem* '"""'
shortstringitem: shortstringchar | escapeseq
longstringitem: longstringchar | escapeseq
shortstringchar:
  <any source character except "\" or newline or the quote>
longstringchar: <any source character except "\">
escapeseq: "\" NL
  | "\\" | "\'" | '\"'
  | "\a" | "\b" | "\f" | "\n" | "\r" | "\t" | "\v"
  | "\ooo" | "\xhh"
  | "\uxxxx" | "\Uxxxxxxxx" | "\N{name}"

Die folgenden zusätzlichen Einschränkungen gelten nur für Bytes-Literale (stringliteral-Tokens mit b oder B im stringprefix)

• Jedes shortstringchar oder longstringchar muss ein Zeichen zwischen 1 und 127 (einschließlich) sein, unabhängig von jeglicher Kodierungsdeklaration [2] in der Quelldatei.
• Die Unicode-spezifischen Escape-Sequenzen \uxxxx, \Uxxxxxxxx und \N{name} sind in Python 2.x nicht erkannt und in Python 3000 verboten.

Benachbarte Bytes-Literale unterliegen denselben Verkettungsregeln wie benachbarte String-Literale [3]. Ein Bytes-Literal, das einem String-Literal benachbart ist, ist ein Fehler.

Semantik

Jede Auswertung eines Bytes-Literals erzeugt ein neues bytes-Objekt. Die Bytes im neuen Objekt sind die Bytes, die durch die shortstringitem- oder longstringitem-Teile des Literals dargestellt werden, in derselben Reihenfolge.

Begründung

Die vorgeschlagene Syntax bietet einen saubereren Migrationspfad von Python 2.x zu Python 3000 für die meisten Code, der 8-Bit-Strings beinhaltet. Das Beibehalten der alten 8-Bit-Bedeutung eines String-Literals ist meist so einfach wie das Hinzufügen eines b-Präfixes. Die einzige Ausnahme sind Python 2.x-Strings, die Bytes > 127 enthalten und die mit Escape-Sequenzen neu geschrieben werden müssen. Das Transkodieren einer Quelldatei von einer Kodierung in eine andere und das Korrigieren der Kodierungsdeklaration sollte die Bedeutung des Programms erhalten. Python 2.x Nicht-Unicode-Strings verstoßen gegen dieses Prinzip; Python 3000 Bytes-Literale sollten dies nicht tun.

Ein String-Literal mit einem b im Präfix ist in Python 2.5 immer ein Syntaxfehler, daher kann diese Syntax in Python 2.6 zusammen mit dem bytes-Typ eingeführt werden.

Ein Bytes-Literal erzeugt bei jeder Auswertung ein neues Objekt, wie Listenanzeigen und im Gegensatz zu String-Literalen. Dies ist notwendig, da Bytes-Literale, wie Listen und im Gegensatz zu Strings, veränderlich sind [4].

Referenzimplementierung

Thomas Wouters hat eine Implementierung in den Py3K-Zweig eingecheckt, r53872.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.