Neuigkeiten in Python 3.3

Dieser Artikel erklärt die neuen Funktionen in Python 3.3 im Vergleich zu 3.2. Python 3.3 wurde am 29. September 2012 veröffentlicht. Vollständige Details finden Sie im Changelog.

Siehe auch

PEP 398 - Python 3.3 Release-Zeitplan

Zusammenfassung – Release-Highlights

Neue Syntaxfunktionen

  • Neuer yield from Ausdruck für Generator-Delegation.

  • Die u'unicode' Syntax wird wieder für str-Objekte akzeptiert.

Neue Bibliotheksmodule

  • faulthandler (hilft beim Debugging von Low-Level-Abstürzen)

  • ipaddress (High-Level-Objekte, die IP-Adressen und Masken darstellen)

  • lzma (Daten komprimieren mit dem XZ / LZMA-Algorithmus)

  • unittest.mock (Teile Ihres zu testenden Systems durch Mock-Objekte ersetzen)

  • venv (Python virtuelle Umgebungen, wie im beliebten Paket virtualenv)

Neue eingebaute Funktionen

Verbesserungen der Implementierung

Signifikant verbesserte Bibliotheksmodule

  • C-Beschleuniger für das decimal-Modul.

  • Bessere Unicode-Handhabung im email-Modul (vorläufig).

Sicherheitsverbesserungen

  • Hash-Randomisierung ist standardmäßig aktiviert.

Lesen Sie weiter für eine umfassende Liste der für den Benutzer sichtbaren Änderungen.

PEP 405: Virtuelle Umgebungen

Virtuelle Umgebungen helfen bei der Erstellung separater Python-Installationen, während eine systemweite Basisinstallation geteilt wird, um die Wartung zu erleichtern. Virtuelle Umgebungen haben ihre eigene Sammlung privater Site-Pakete (d. h. lokal installierter Bibliotheken) und sind optional von den systemweiten Site-Paketen getrennt. Ihr Konzept und ihre Implementierung sind vom beliebten virtualenv Drittanbieterpaket inspiriert, profitieren aber von einer engeren Integration mit dem Interpreter-Kern.

Dieses PEP fügt das venv-Modul für den programmatischen Zugriff und das Skript pyvenv für den Kommandozeilenzugriff und die Verwaltung hinzu. Der Python-Interpreter sucht nach einer Datei pyvenv.cfg, deren Existenz die Basis des Verzeichnisbaums einer virtuellen Umgebung signalisiert.

Siehe auch

PEP 405 - Python Virtuelle Umgebungen

PEP geschrieben von Carl Meyer; Implementierung von Carl Meyer und Vinay Sajip

PEP 420: Implizite Namespace-Pakete

Nativer Support für Verzeichnisse, die keine __init__.py Marker-Dateien benötigen und automatisch mehrere Pfadsegmente umspannen können (inspiriert von verschiedenen Drittanbieteransätzen für Namespace-Pakete, wie in PEP 420 beschrieben)

Siehe auch

PEP 420 - Implizite Namespace-Pakete

PEP geschrieben von Eric V. Smith; Implementierung von Eric V. Smith und Barry Warsaw

PEP 3118: Neue Memoryview-Implementierung und Pufferprotokoll-Dokumentation

Die Implementierung von PEP 3118 wurde erheblich verbessert.

Die neue Memoryview-Implementierung behebt umfassend alle Besitz- und Lebenszeitprobleme von dynamisch zugewiesenen Feldern in der Py_buffer Struktur, die zu mehreren Absturzberichten geführt hatten. Zusätzlich wurden mehrere Funktionen behoben, die bei nicht zusammenhängenden oder mehrdimensionalen Eingaben abgestürzt waren oder falsche Ergebnisse lieferten.

Das Memoryview-Objekt verfügt nun über eine PEP-3118-konforme getbufferproc(), die den Anfragetyp des Konsumenten prüft. Viele neue Funktionen wurden hinzugefügt, von denen die meisten in voller Allgemeinheit für nicht zusammenhängende Arrays und Arrays mit Sub-Offsets funktionieren.

Die Dokumentation wurde aktualisiert und erklärt deutlich die Verantwortlichkeiten für Exporteure und Konsumenten. Pufferanforderungsflags werden in grundlegende und zusammengesetzte Flags gruppiert. Die Speicherlayout von nicht zusammenhängenden und mehrdimensionalen NumPy-ähnlichen Arrays wird erklärt.

Funktionen

  • Alle nativen Einzelzeichen-Format-Spezifizierer in der struct-Modul-Syntax (optional mit '@' präfixiert) werden nun unterstützt.

  • Mit einigen Einschränkungen erlaubt die cast()-Methode die Änderung von Format und Form von C-zusammenhängenden Arrays.

  • Mehrdimensionale Listenrepräsentationen werden für jeden Array-Typ unterstützt.

  • Mehrdimensionale Vergleiche werden für jeden Array-Typ unterstützt.

  • Eindimensionale Memoryviews von hashbaren (nur-lesbar) Typen mit den Formaten B, b oder c sind nun hashbar. (Beigetragen von Antoine Pitrou in bpo-13411.)

  • Arbiträres Slicing von jedem eindimensionalen Array-Typ wird unterstützt. Zum Beispiel ist es jetzt möglich, ein Memoryview in O(1) durch Verwendung eines negativen Schritts umzukehren.

API-Änderungen

  • Die maximale Anzahl von Dimensionen ist offiziell auf 64 begrenzt.

  • Die Darstellung von leeren Formen, Schritten und Sub-Offsets ist nun ein leeres Tupel anstelle von None.

  • Der Zugriff auf ein Memoryview-Element mit dem Format 'B' (vorzeichenlose Bytes) gibt nun eine Ganzzahl zurück (gemäß der struct-Modul-Syntax). Um ein Bytes-Objekt zurückzugeben, muss die Ansicht zuerst in 'c' umgewandelt werden.

  • Memoryview-Vergleiche verwenden nun die logische Struktur der Operanden und vergleichen alle Array-Elemente nach Wert. Alle Formatstrings in struct-Modul-Syntax werden unterstützt. Ansichten mit nicht erkannten Formatstrings sind weiterhin zulässig, werden aber immer als ungleich verglichen, unabhängig vom Inhalt der Ansicht.

  • Weitere Änderungen finden Sie unter Build- und C-API-Änderungen und Portierung von C-Code.

(Beigetragen von Stefan Krah in bpo-10181.)

Siehe auch

PEP 3118 - Überarbeitung des Pufferprotokolls

PEP 393: Flexible String-Darstellung

Der Unicode-String-Typ wurde geändert, um mehrere interne Darstellungen zu unterstützen, abhängig vom Zeichen mit der höchsten Unicode-Ordninalzahl (1, 2 oder 4 Bytes) im dargestellten String. Dies ermöglicht eine speichereffiziente Darstellung in gängigen Fällen, bietet aber Zugriff auf volles UCS-4 auf allen Systemen. Zur Kompatibilität mit bestehenden APIs können mehrere Darstellungen parallel existieren; im Laufe der Zeit sollte diese Kompatibilität schrittweise abgeschafft werden.

Auf Python-Seite sollte diese Änderung keine Nachteile haben.

Auf der C-API-Seite ist PEP 393 vollständig abwärtskompatibel. Die Legacy-API sollte mindestens fünf Jahre lang verfügbar bleiben. Anwendungen, die die Legacy-API verwenden, werden nicht vollständig von der Speicherreduzierung profitieren oder - schlimmer noch - möglicherweise etwas mehr Speicher verbrauchen, da Python möglicherweise zwei Versionen jedes Strings (im Legacy-Format und im neuen effizienten Speicher) pflegen muss.

Funktionalität

Die durch PEP 393 eingeführten Änderungen sind die folgenden:

  • Python unterstützt nun immer den vollen Bereich von Unicode-Codepunkten, einschließlich der Nicht-BMP-Punkte (d. h. von U+0000 bis U+10FFFF). Die Unterscheidung zwischen schmalen und breiten Builds existiert nicht mehr und Python verhält sich nun wie ein breiter Build, auch unter Windows.

  • Mit dem Ende der schmalen Builds wurden auch die spezifischen Probleme schmaler Builds behoben, zum Beispiel:

    • len() gibt nun immer 1 für Nicht-BMP-Zeichen zurück, also len('\U0010FFFF') == 1;

    • Surrogatpaare werden in String-Literalen nicht rekombiniert, also '\uDBFF\uDFFF' != '\U0010FFFF';

    • das Indizieren oder Slicen von Nicht-BMP-Zeichen gibt den erwarteten Wert zurück, also gibt '\U0010FFFF'[0] nun '\U0010FFFF' und nicht '\uDBFF' zurück;

    • alle anderen Funktionen in der Standardbibliothek behandeln Nicht-BMP-Codepunkte nun korrekt.

  • Der Wert von sys.maxunicode ist nun immer 1114111 (0x10FFFF in Hexadezimal). Die Funktion PyUnicode_GetMax() gibt weiterhin entweder 0xFFFF oder 0x10FFFF aus Kompatibilitätsgründen zurück und sollte nicht mit der neuen Unicode-API verwendet werden (siehe bpo-13054).

  • Das ./configure Flag --with-wide-unicode wurde entfernt.

Leistung und Ressourcenverbrauch

Die Speicherung von Unicode-Strings hängt nun vom höchsten Codepunkt im String ab:

  • reine ASCII- und Latin1-Strings (U+0000-U+00FF) verwenden 1 Byte pro Codepunkt;

  • BMP-Strings (U+0000-U+FFFF) verwenden 2 Bytes pro Codepunkt;

  • Nicht-BMP-Strings (U+10000-U+10FFFF) verwenden 4 Bytes pro Codepunkt.

Der Nettoeffekt ist, dass für die meisten Anwendungen der Speicherverbrauch von String-Speichern signifikant sinken sollte – insbesondere im Vergleich zu früheren breiten Unicode-Builds –, da in vielen Fällen Strings selbst in internationalen Kontexten rein ASCII sind (da viele Strings Nicht-Menschen-Sprachdaten speichern, wie XML-Fragmente, HTTP-Header, JSON-kodierte Daten usw.). Wir hoffen auch, dass dies aus den gleichen Gründen die CPU-Cache-Effizienz bei nicht trivialen Anwendungen erhöht. Der Speicherverbrauch von Python 3.3 ist bei einem Django-Benchmark um das Zwei- bis Dreifache geringer als bei Python 3.2 und etwas besser als bei Python 2.7 (siehe PEP für Details).

Siehe auch

PEP 393 - Flexible String-Darstellung

PEP geschrieben von Martin von Löwis; Implementierung von Torsten Becker und Martin von Löwis.

PEP 397: Python Launcher für Windows

Das Windows-Installationsprogramm für Python 3.3 enthält nun eine py Launcher-Anwendung, die verwendet werden kann, um Python-Anwendungen versionsunabhängig zu starten.

Dieser Launcher wird implizit aufgerufen, wenn *.py Dateien per Doppelklick geöffnet werden. Wenn nur eine einzige Python-Version auf dem System installiert ist, wird diese Version zum Ausführen der Datei verwendet. Wenn mehrere Versionen installiert sind, wird standardmäßig die neueste Version verwendet, dies kann jedoch durch Hinzufügen einer Unix-ähnlichen „Shebang-Zeile“ im Python-Skript überschrieben werden.

Der Launcher kann auch explizit von der Kommandozeile als py-Anwendung verwendet werden. Das Ausführen von py folgt denselben Versionsauswahlregeln wie das implizite Starten von Skripten, aber eine spezifischere Version kann durch Übergabe geeigneter Argumente ausgewählt werden (wie z. B. -3, um Python 3 anzufordern, wenn auch Python 2 installiert ist, oder -2.6, um explizit eine frühere Python-Version anzufordern, wenn eine neuere Version installiert ist).

Zusätzlich zum Launcher enthält das Windows-Installationsprogramm nun eine Option, das neu installierte Python zum System-PATH hinzuzufügen. (Beigetragen von Brian Curtin in bpo-3561.)

Siehe auch

PEP 397 - Python Launcher für Windows

PEP geschrieben von Mark Hammond und Martin v. Löwis; Implementierung von Vinay Sajip.

Launcher-Dokumentation: Python-Installationsmanager

Änderung des Installations-PATH: Python-Installationsmanager

PEP 3151: Überarbeitung der OS- und IO-Ausnahmehierarchie

Die Hierarchie der durch Betriebssystemfehler ausgelösten Ausnahmen ist nun sowohl vereinfacht als auch feingranularer.

Sie müssen sich nicht mehr darum kümmern, den geeigneten Ausnahmetyp zwischen OSError, IOError, EnvironmentError, WindowsError, mmap.error, socket.error oder select.error zu wählen. All diese Ausnahmetypen sind nun nur noch einer: OSError. Die anderen Namen bleiben aus Kompatibilitätsgründen als Aliase erhalten.

Außerdem ist es nun einfacher, eine spezifische Fehlerbedingung abzufangen. Anstatt das errno Attribut (oder args[0]) für eine bestimmte Konstante aus dem errno Modul zu inspizieren, können Sie die entsprechende OSError-Unterklasse abfangen. Die verfügbaren Unterklassen sind die folgenden:

Und ConnectionError selbst hat feingranularere Unterklassen:

Dank der neuen Ausnahmen können gängige Verwendungen von errno vermieden werden. Zum Beispiel kann der folgende für Python 3.2 geschriebene Code

from errno import ENOENT, EACCES, EPERM

try:
    with open("document.txt") as f:
        content = f.read()
except IOError as err:
    if err.errno == ENOENT:
        print("document.txt file is missing")
    elif err.errno in (EACCES, EPERM):
        print("You are not allowed to read document.txt")
    else:
        raise

jetzt ohne den errno Import und ohne manuelle Inspektion von Ausnahmeattributen geschrieben werden:

try:
    with open("document.txt") as f:
        content = f.read()
except FileNotFoundError:
    print("document.txt file is missing")
except PermissionError:
    print("You are not allowed to read document.txt")

Siehe auch

PEP 3151 - Überarbeitung der OS- und IO-Ausnahmehierarchie

PEP geschrieben und implementiert von Antoine Pitrou

PEP 380: Syntax für die Delegierung an einen Untergenerator

PEP 380 fügt den yield from Ausdruck hinzu, der es einem Generator ermöglicht, einen Teil seiner Operationen an einen anderen Generator zu delegieren. Dies ermöglicht es, einen Codeabschnitt, der yield enthält, auszufaktorisieren und in einen anderen Generator zu legen. Zusätzlich darf der Untergenerator mit einem Wert zurückkehren, und dieser Wert wird dem delegierenden Generator zur Verfügung gestellt.

Obwohl hauptsächlich für die Delegierung an einen Untergenerator konzipiert, erlaubt der yield from Ausdruck tatsächlich die Delegierung an beliebige Subiteratoren.

Für einfache Iteratoren ist yield from iterable im Wesentlichen nur eine verkürzte Form von for item in iterable: yield item

>>> def g(x):
...     yield from range(x, 0, -1)
...     yield from range(x)
...
>>> list(g(5))
[5, 4, 3, 2, 1, 0, 1, 2, 3, 4]

Im Gegensatz zu einer gewöhnlichen Schleife erlaubt yield from Untergeneratoren, gesendete und geworfene Werte direkt aus dem aufrufenden Gültigkeitsbereich zu empfangen und einen Endwert an den äußeren Generator zurückzugeben.

>>> def accumulate():
...     tally = 0
...     while 1:
...         next = yield
...         if next is None:
...             return tally
...         tally += next
...
>>> def gather_tallies(tallies):
...     while 1:
...         tally = yield from accumulate()
...         tallies.append(tally)
...
>>> tallies = []
>>> acc = gather_tallies(tallies)
>>> next(acc)  # Ensure the accumulator is ready to accept values
>>> for i in range(4):
...     acc.send(i)
...
>>> acc.send(None)  # Finish the first tally
>>> for i in range(5):
...     acc.send(i)
...
>>> acc.send(None)  # Finish the second tally
>>> tallies
[6, 10]

Das Hauptprinzip, das diese Änderung antreibt, ist es, es selbst Generatoren, die für die Verwendung mit den Methoden send und throw konzipiert sind, zu ermöglichen, so einfach in mehrere Untergeneratoren aufgeteilt zu werden, wie eine einzelne große Funktion in mehrere Unterfunktionen aufgeteilt werden kann.

Siehe auch

PEP 380 - Syntax für die Delegierung an einen Untergenerator

PEP geschrieben von Greg Ewing; Implementierung von Greg Ewing, integriert in 3.3 von Renaud Blanch, Ryan Kelly und Nick Coghlan; Dokumentation von Zbigniew Jędrzejewski-Szmek und Nick Coghlan

PEP 409: Unterdrückung des Ausnahme-Kontexts

PEP 409 führt eine neue Syntax ein, die es ermöglicht, die Anzeige des verketteten Ausnahme-Kontexts zu deaktivieren. Dies ermöglicht sauberere Fehlermeldungen in Anwendungen, die zwischen Ausnahmetypen konvertieren.

>>> class D:
...     def __init__(self, extra):
...         self._extra_attributes = extra
...     def __getattr__(self, attr):
...         try:
...             return self._extra_attributes[attr]
...         except KeyError:
...             raise AttributeError(attr) from None
...
>>> D({}).x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in __getattr__
AttributeError: x

Ohne den from None Suffix, um die Ursache zu unterdrücken, würde die ursprüngliche Ausnahme standardmäßig angezeigt werden.

>>> class C:
...     def __init__(self, extra):
...         self._extra_attributes = extra
...     def __getattr__(self, attr):
...         try:
...             return self._extra_attributes[attr]
...         except KeyError:
...             raise AttributeError(attr)
...
>>> C({}).x
Traceback (most recent call last):
  File "<stdin>", line 6, in __getattr__
KeyError: 'x'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in __getattr__
AttributeError: x

Es geht keine Debugging-Funktionalität verloren, da der ursprüngliche Ausnahme-Kontext bei Bedarf verfügbar bleibt (z. B. wenn eine zwischengeschaltete Bibliothek fälschlicherweise wertvolle zugrunde liegende Details unterdrückt hat).

>>> try:
...     D({}).x
... except AttributeError as exc:
...     print(repr(exc.__context__))
...
KeyError('x',)

Siehe auch

PEP 409 - Unterdrückung des Ausnahme-Kontexts

PEP geschrieben von Ethan Furman; implementiert von Ethan Furman und Nick Coghlan.

PEP 414: Explizite Unicode-Literale

Um den Übergang von Python 2 für Unicode-bewusste Python-Anwendungen, die intensiv Unicode-Literale verwenden, zu erleichtern, unterstützt Python 3.3 wieder das „u“-Präfix für String-Literale. Dieses Präfix hat in Python 3 keine semantische Bedeutung und dient ausschließlich dazu, die Anzahl rein mechanischer Änderungen bei der Migration zu Python 3 zu reduzieren, damit sich Entwickler auf die wichtigeren semantischen Änderungen (wie die strengere standardmäßige Trennung von Binär- und Textdaten) konzentrieren können.

Siehe auch

PEP 414 - Explizite Unicode-Literale

PEP geschrieben von Armin Ronacher.

PEP 3155: Qualifizierte Namen für Klassen und Funktionen

Funktionen und Klassenobjekte haben ein neues Attribut __qualname__, das den „Pfad“ vom Modultop-Level bis zu ihrer Definition darstellt. Für globale Funktionen und Klassen ist dies dasselbe wie __name__. Für andere Funktionen und Klassen liefert es bessere Informationen darüber, wo sie tatsächlich definiert wurden und wie sie vom globalen Gültigkeitsbereich aus erreichbar sind.

Beispiel mit (nicht gebundenen) Methoden

>>> class C:
...     def meth(self):
...         pass
...
>>> C.meth.__name__
'meth'
>>> C.meth.__qualname__
'C.meth'

Beispiel mit verschachtelten Klassen

>>> class C:
...     class D:
...         def meth(self):
...             pass
...
>>> C.D.__name__
'D'
>>> C.D.__qualname__
'C.D'
>>> C.D.meth.__name__
'meth'
>>> C.D.meth.__qualname__
'C.D.meth'

Beispiel mit verschachtelten Funktionen

>>> def outer():
...     def inner():
...         pass
...     return inner
...
>>> outer().__name__
'inner'
>>> outer().__qualname__
'outer.<locals>.inner'

Die String-Darstellung dieser Objekte wird ebenfalls geändert, um die neuen, präziseren Informationen einzuschließen.

>>> str(C.D)
"<class '__main__.C.D'>"
>>> str(C.D.meth)
'<function C.D.meth at 0x7f46b9fe31e0>'

Siehe auch

PEP 3155 - Qualifizierter Name für Klassen und Funktionen

PEP geschrieben und implementiert von Antoine Pitrou.

PEP 412: Key-Sharing Dictionary

Dictionarys, die zur Speicherung von Objektattributen verwendet werden, können nun einen Teil ihres internen Speichers untereinander teilen (nämlich den Teil, der die Schlüssel und ihre jeweiligen Hashes speichert). Dies reduziert den Speicherverbrauch von Programmen, die viele Instanzen von Nicht-Builtin-Typen erstellen.

Siehe auch

PEP 412 - Key-Sharing Dictionary

PEP geschrieben und implementiert von Mark Shannon.

PEP 362: Funktion Signatur Objekt

Eine neue Funktion inspect.signature() macht die Introspektion von Python-Aufrufbaren einfach und geradlinig. Eine breite Palette von Aufrufbaren wird unterstützt: Python-Funktionen, dekoriert oder nicht, Klassen und Objekte von functools.partial(). Neue Klassen inspect.Signature, inspect.Parameter und inspect.BoundArguments halten Informationen über die Aufruf-Signaturen, wie z.B. Annotationen, Standardwerte, Parameterarten und gebundene Argumente, was das Schreiben von Dekoratoren und jeglichen Code, der Aufruf-Signaturen oder Argumente validiert oder ändert, erheblich vereinfacht.

Siehe auch

PEP 362: - Funktion Signatur Objekt

PEP geschrieben von Brett Cannon, Yury Selivanov, Larry Hastings, Jiwon Seo; implementiert von Yury Selivanov.

PEP 421: Hinzufügen von sys.implementation

Ein neues Attribut im sys-Modul gibt Details preis, die für die Implementierung des aktuell ausgeführten Interpreters spezifisch sind. Die anfängliche Gruppe von Attributen auf sys.implementation sind name, version, hexversion und cache_tag.

Die Absicht von sys.implementation ist es, die von der Standardbibliothek verwendeten implementierungsspezifischen Daten in einem einzigen Namensraum zu konsolidieren. Dies ermöglicht es verschiedenen Python-Implementierungen, eine einzige Codebasis der Standardbibliothek einfacher zu teilen. In seinem anfänglichen Zustand enthält sys.implementation nur einen kleinen Teil der implementierungsspezifischen Daten. Im Laufe der Zeit wird sich dieses Verhältnis verschieben, um die Standardbibliothek portabler zu machen.

Ein Beispiel für verbesserte Portabilität der Standardbibliothek ist cache_tag. Ab Python 3.3 wird sys.implementation.cache_tag von importlib verwendet, um die Einhaltung von PEP 3147 zu unterstützen. Jede Python-Implementierung, die importlib für ihr integriertes Importsystem verwendet, kann cache_tag verwenden, um das Caching-Verhalten für Module zu steuern.

SimpleNamespace

Die Implementierung von sys.implementation führt auch einen neuen Typ in Python ein: types.SimpleNamespace. Im Gegensatz zu einem Mapping-basierten Namespace wie dict ist SimpleNamespace attributbasiert, wie object. Im Gegensatz zu object sind SimpleNamespace-Instanzen jedoch beschreibbar. Das bedeutet, dass Sie den Namensraum durch normalen Attributzugriff hinzufügen, entfernen und ändern können.

Siehe auch

PEP 421 - Hinzufügen von sys.implementation

PEP geschrieben und implementiert von Eric Snow.

Verwendung von importlib als Implementierung des Imports

bpo-2377 - Ersetzen Sie __import__ durch importlib.__import__ bpo-13959 - Teile von imp in reinem Python neu implementieren bpo-14605 - Machen Sie die Import-Mechanismen explizit bpo-14646 - Loader müssen __loader__ und __package__ setzen

Die Funktion __import__() wird nun von importlib.__import__() angetrieben. Diese Arbeit führt zur Fertigstellung der „Phase 2“ von PEP 302. Diese Änderung hat mehrere Vorteile. Erstens hat sie es ermöglicht, mehr von den Mechanismen, die den Import antreiben, freizulegen, anstatt implizit und im C-Code verborgen zu sein. Sie bietet auch eine einzige Implementierung für alle Python-VMs, die Python 3.3 unterstützen, und trägt so dazu bei, VM-spezifische Abweichungen in der Import-Semantik zu beenden. Und schließlich erleichtert sie die Wartung des Imports und ermöglicht zukünftiges Wachstum.

Für den normalen Benutzer sollte es keine sichtbare Änderung der Semantik geben. Für diejenigen, deren Code derzeit den Import manipuliert oder den Import programmatisch aufruft, sind die möglicherweise erforderlichen Code-Änderungen im Abschnitt Portierung von Python-Code dieses Dokuments abgedeckt.

Neue APIs

Einer der großen Vorteile dieser Arbeit ist die Offenlegung dessen, was zur Funktionsweise der Import-Anweisung gehört. Das bedeutet, dass die verschiedenen Importer, die früher implizit waren, nun vollständig als Teil des importlib-Pakets freigelegt sind.

Die in importlib.abc definierten abstrakten Basisklassen wurden erweitert, um korrekt zwischen Meta-Path-Finder und Path-Entry-Finder zu unterscheiden, indem importlib.abc.MetaPathFinder und importlib.abc.PathEntryFinder eingeführt wurden. Die alte ABC von importlib.abc.Finder wird nun nur noch aus Kompatibilitätsgründen bereitgestellt und erzwingt keine Methodenanforderungen.

Im Hinblick auf Finder exponiert importlib.machinery.FileFinder den Mechanismus, der zum Suchen von Quell- und Bytecode-Dateien eines Moduls verwendet wird. Zuvor war diese Klasse ein implizites Mitglied von sys.path_hooks.

Für Loader hilft die neue abstrakte Basisklasse importlib.abc.FileLoader dabei, einen Loader zu schreiben, der das Dateisystem als Speichermechanismus für den Code eines Moduls verwendet. Die Loader für Quelldateien (importlib.machinery.SourceFileLoader), quelllose Bytecode-Dateien (importlib.machinery.SourcelessFileLoader) und Erweiterungsmodule (importlib.machinery.ExtensionFileLoader) sind nun direkt verwendbar.

ImportError hat nun die Attribute name und path, die gesetzt werden, wenn relevante Daten zur Verfügung stehen. Die Meldung für fehlgeschlagene Imports enthält nun auch den vollständigen Namen des Moduls anstelle nur des letzten Teils des Modulnamens.

Die Funktion importlib.invalidate_caches() ruft nun die Methode mit demselben Namen auf allen in sys.path_importer_cache zwischengespeicherten Findern auf, um gespeicherte Zustände bei Bedarf zu bereinigen.

Sichtbare Änderungen

Mögliche erforderliche Änderungen am Code finden Sie im Abschnitt Porting von Python-Code.

Über das hinaus, was importlib nun preisgibt, gibt es weitere sichtbare Änderungen am Importmechanismus. Die wichtigste ist, dass sys.meta_path und sys.path_hooks nun alle Meta-Path-Finder und Pfad-Eintrag-Hooks speichern, die von import verwendet werden. Zuvor waren die Finder implizit und im C-Code von import versteckt, anstatt direkt offengelegt zu werden. Das bedeutet, dass man nun leicht die Reihenfolge der verschiedenen Finder ändern oder Elemente entfernen kann, um den eigenen Bedürfnissen gerecht zu werden.

Eine weitere Änderung ist, dass alle Module ein Attribut __loader__ haben, das den Loader speichert, der zum Erstellen des Moduls verwendet wurde. PEP 302 wurde aktualisiert, um dieses Attribut für Loader obligatorisch zu machen. In Zukunft können sich die Leute auf die Existenz des Attributs verlassen, sobald 3rd-Party-Loader aktualisiert wurden. Bis dahin setzt import das Modul nach dem Laden.

Loader sollen nun auch das Attribut __package__ gemäß PEP 366 setzen. Auch hier setzt import selbst dies bereits auf allen Loadern aus importlib und setzt das Attribut nach dem Laden.

None wird nun in sys.path_importer_cache eingefügt, wenn kein Finder auf sys.path_hooks gefunden werden kann. Da imp.NullImporter nicht direkt auf sys.path_hooks offengelegt wird, konnte man sich nicht mehr darauf verlassen, dass es immer als Wert für "kein Finder gefunden" verfügbar ist.

Alle anderen Änderungen beziehen sich auf semantische Änderungen, die bei der Aktualisierung von Code für Python 3.3 berücksichtigt werden sollten, und sollten daher im Abschnitt Porting von Python-Code dieses Dokuments gelesen werden.

(Implementierung von Brett Cannon)

Andere Sprachänderungen

Einige kleinere Änderungen am Kern der Python-Sprache sind:

  • Unterstützung für Unicode-Namensaliase und benannte Sequenzen hinzugefügt. Sowohl unicodedata.lookup() als auch '\N{...}' lösen nun Namensaliase auf, und unicodedata.lookup() löst auch benannte Sequenzen auf.

    (Beigetragen von Ezio Melotti in bpo-12753.)

  • Unicode-Datenbank aktualisiert auf UCD Version 6.1.0

  • Gleichheitsvergleiche bei range()-Objekten geben nun ein Ergebnis zurück, das die Gleichheit der zugrunde liegenden Sequenzen widerspiegelt, die von diesen Range-Objekten generiert werden. (bpo-13201)

  • Die Methoden count(), find(), rfind(), index() und rindex() von bytes- und bytearray-Objekten akzeptieren nun eine Ganzzahl zwischen 0 und 255 als erstes Argument.

    (Beigetragen von Petri Lehtinen in bpo-12170.)

  • Die Methoden rjust(), ljust() und center() von bytes und bytearray akzeptieren nun ein bytearray für das Argument fill. (Beigetragen von Petri Lehtinen in bpo-12380.)

  • Neue Methoden wurden zu list und bytearray hinzugefügt: copy() und clear() (bpo-10516). Folglich definiert collections.abc.MutableSequence nun ebenfalls eine Methode clear() (bpo-11388).

  • Rohe Byte-Literale können nun als rb"..." sowie als br"..." geschrieben werden.

    (Beigetragen von Antoine Pitrou in bpo-13748.)

  • dict.setdefault() führt nun nur eine einzige Suche nach dem gegebenen Schlüssel durch, was es bei der Verwendung mit integrierten Typen atomar macht.

    (Beigetragen von Filip Gruszczyński in bpo-13521.)

  • Die Fehlermeldungen, die bei einer Funktionsaufrufs-Übereinstimmung mit der Funktionssignatur erzeugt werden, wurden erheblich verbessert.

    (Beigetragen von Benjamin Peterson.)

Eine feingranularere Import-Sperre

Frühere Versionen von CPython verließen sich immer auf eine globale Import-Sperre. Dies führte zu unerwarteten Problemen, wie z. B. Deadlocks, wenn der Import eines Moduls als Nebeneffekt Code in einem anderen Thread auslöste. Ungeschickte Workarounds wurden manchmal verwendet, wie z. B. die C-API-Funktion PyImport_ImportModuleNoBlock().

In Python 3.3 nimmt das Importieren eines Moduls eine Sperre pro Modul. Dies serialisiert korrekt den Import eines bestimmten Moduls aus mehreren Threads (wodurch unvollständig initialisierte Module nicht zugänglich werden) und eliminiert gleichzeitig die oben genannten Probleme.

(Beigetragen von Antoine Pitrou in bpo-9260.)

Eingebaute Funktionen und Typen

  • open() erhält einen neuen Parameter opener: Der zugrunde liegende Dateideskriptor für das Datei-Objekt wird dann durch Aufrufen von opener mit (file, flags) erhalten. Er kann verwendet werden, um benutzerdefinierte Flags wie z. B. os.O_CLOEXEC zu verwenden. Der Modus 'x' wurde hinzugefügt: Öffnen zur exklusiven Erstellung, Fehlschlag, wenn die Datei bereits existiert.

  • print(): Das Schlüsselwortargument flush wurde hinzugefügt. Wenn das Schlüsselwortargument flush wahr ist, wird der Stream zwangsweise geleert.

  • hash(): Hash-Randomisierung ist standardmäßig aktiviert, siehe object.__hash__() und PYTHONHASHSEED.

  • Der Typ str erhält eine neue Methode casefold(): Gibt eine kleingeschriebene Kopie des Strings zurück. Kleingeschriebene Strings können für nicht-case-sensitives Matching verwendet werden. Zum Beispiel gibt 'ß'.casefold() 'ss' zurück.

  • Die Dokumentation der Sequenzen wurde substantiv überarbeitet, um die Unterscheidung zwischen binären/Text-Sequenzen besser zu erklären und spezifische Dokumentationsabschnitte für die einzelnen integrierten Sequenztypen bereitzustellen (bpo-4966).

Neue Module

faulthandler

Dieses neue Debugging-Modul faulthandler enthält Funktionen zum expliziten Ausgeben von Python-Tracebacks bei einem Fehler (ein Absturz wie ein Segmentierungsfehler), nach einem Timeout oder bei einem Benutzersignal. Rufen Sie faulthandler.enable() auf, um Fehlerhandler für die Signale SIGSEGV, SIGFPE, SIGABRT, SIGBUS und SIGILL zu installieren. Sie können diese auch beim Start aktivieren, indem Sie die Umgebungsvariable PYTHONFAULTHANDLER setzen oder die Kommandozeilenoption -X faulthandler verwenden.

Beispiel für einen Segmentierungsfehler unter Linux

$ python -q -X faulthandler
>>> import ctypes
>>> ctypes.string_at(0)
Fatal Python error: Segmentation fault

Current thread 0x00007fb899f39700:
  File "/home/python/cpython/Lib/ctypes/__init__.py", line 486 in string_at
  File "<stdin>", line 1 in <module>
Segmentation fault

ipaddress

Das neue Modul ipaddress bietet Werkzeuge zum Erstellen und Bearbeiten von Objekten, die IPv4- und IPv6-Adressen, Netzwerke und Schnittstellen (d. h. eine IP-Adresse, die mit einem bestimmten IP-Subnetz verbunden ist) darstellen.

(Beigetragen von Google und Peter Moody in PEP 3144.)

lzma

Das neu hinzugefügte Modul lzma bietet Datenkomprimierung und -dekomprimierung unter Verwendung des LZMA-Algorithmus, einschließlich Unterstützung für die Dateiformate .xz und .lzma.

(Beigetragen von Nadeem Vawda und Per Øyvind Karlsen in bpo-6715.)

Verbesserte Module

abc

Verbesserte Unterstützung für abstrakte Basisklassen, die Deskriptoren enthalten, die mit abstrakten Methoden zusammengesetzt sind. Der empfohlene Ansatz zur Deklaration von abstrakten Deskriptoren besteht nun darin, __isabstractmethod__ als dynamisch aktualisierte Eigenschaft bereitzustellen. Die integrierten Deskriptoren wurden entsprechend aktualisiert.

(Beigetragen von Darren Dale in bpo-11610.)

abc.ABCMeta.register() gibt nun die registrierte Unterklasse zurück, was bedeutet, dass sie nun als Klassen-Decorator verwendet werden kann (bpo-10868).

array

Das Modul array unterstützt den Typ long long mit den Typencodes q und Q.

(Beigetragen von Oren Tirosh und Hirokazu Yamamoto in bpo-1172711.)

base64

Nur-ASCII-Unicode-Strings werden nun von den Dekodierungsfunktionen der modernen Schnittstelle von base64 akzeptiert. Zum Beispiel gibt base64.b64decode('YWJj') b'abc' zurück. (Beigetragen von Catalin Iacob in bpo-13641.)

binascii

Zusätzlich zu den binären Objekten, die sie normalerweise akzeptieren, akzeptieren die a2b_-Funktionen nun alle auch nur ASCII-Strings als Eingabe. (Beigetragen von Antoine Pitrou in bpo-13637.)

bz2

Das Modul bz2 wurde von Grund auf neu geschrieben. Dabei wurden mehrere neue Funktionen hinzugefügt

  • Neue Funktion bz2.open(): Öffnet eine bzip2-komprimierte Datei im binären oder Textmodus.

  • bz2.BZ2File kann nun von und zu beliebigen dateiähnlichen Objekten lesen und schreiben, mittels des fileobj-Arguments des Konstruktors.

    (Beigetragen von Nadeem Vawda in bpo-5863.)

  • bz2.BZ2File und bz2.decompress() können nun Multi-Stream-Eingaben dekomprimieren (wie z.B. die vom Tool pbzip2 erzeugten). bz2.BZ2File kann nun auch verwendet werden, um diesen Dateityp zu erstellen, unter Verwendung des Modus 'a' (anhängen).

    (Beigetragen von Nir Aides in bpo-1625.)

  • bz2.BZ2File implementiert nun die gesamte API von io.BufferedIOBase, mit Ausnahme der Methoden detach() und truncate().

codecs

Der Codec mbcs wurde neu geschrieben, um die Fehlerbehandler replace und ignore auf allen Windows-Versionen korrekt zu behandeln. Der Codec mbcs unterstützt nun alle Fehlerbehandler, anstatt nur replace zum Kodieren und ignore zum Dekodieren.

Ein neuer, nur für Windows verfügbarer Codec wurde hinzugefügt: cp65001 (bpo-13216). Dies ist die Windows-Codepage 65001 (Windows UTF-8, CP_UTF8). Sie wird beispielsweise von sys.stdout verwendet, wenn die Konsolenausgabe-Codepage auf cp65001 gesetzt ist (z. B. mit dem Befehl chcp 65001).

Multibyte CJK-Dekoder resynchronisieren nun schneller. Sie ignorieren nur das erste Byte einer ungültigen Byte-Sequenz. Zum Beispiel gibt b'\xff\n'.decode('gb2312', 'replace') nun nach dem Ersatzzeichen ein \n zurück.

(bpo-12016)

Inkrementelle CJK-Codec-Encoder werden nicht mehr bei jedem Aufruf ihrer encode()-Methoden zurückgesetzt. Zum Beispiel

>>> import codecs
>>> encoder = codecs.getincrementalencoder('hz')('strict')
>>> b''.join(encoder.encode(x) for x in '\u52ff\u65bd\u65bc\u4eba\u3002 Bye.')
b'~{NpJ)l6HK!#~} Bye.'

Dieses Beispiel liefert b'~{Np~}~{J)~}~{l6~}~{HK~}~{!#~} Bye.' mit älteren Python-Versionen.

(bpo-12100)

Der Codec unicode_internal wurde als veraltet markiert.

collections

Hinzufügung einer neuen Klasse ChainMap, um eine Anzahl von Abbildungen als eine Einheit zu behandeln. (Geschrieben von Raymond Hettinger für bpo-11089, öffentlich gemacht in bpo-11297.)

Die abstrakten Basisklassen wurden in ein neues Modul collections.abc verschoben, um zwischen den abstrakten und den konkreten Kollektionsklassen besser zu unterscheiden. Aliase für ABCs sind weiterhin im Modul collections vorhanden, um bestehende Imports zu erhalten. (bpo-11085)

Die Klasse Counter unterstützt nun die unären Operatoren + und - sowie die In-place-Operatoren +=, -=, |= und &=. (Beigetragen von Raymond Hettinger in bpo-13121.)

contextlib

contextlib.ExitStack bietet nun eine solide Grundlage für die programmatische Manipulation von Kontextmanagern und ähnliche Bereinigungsfunktionalitäten. Im Gegensatz zur früheren contextlib.nested API (die als veraltet markiert und entfernt wurde) ist die neue API so konzipiert, dass sie unabhängig davon korrekt funktioniert, ob Kontextmanager ihre Ressourcen in ihrer __init__-Methode (z. B. Datei-Objekte) oder in ihrer __enter__-Methode (z. B. Synchronisierungsobjekte aus dem Modul threading) abrufen.

(bpo-13585)

crypt

Hinzufügung von Salt und dem Modular Crypt Format (Hashing-Methode) sowie der Funktion mksalt() zum Modul crypt.

(bpo-10924)

curses

  • Wenn das Modul curses mit der ncursesw-Bibliothek verknüpft ist, werden Unicode-Funktionen verwendet, wenn Unicode-Strings oder Zeichen übergeben werden (z. B. waddwstr()), und andernfalls Byte-Funktionen (z. B. waddstr()).

  • Verwenden Sie die Locale-Kodierung anstelle von utf-8, um Unicode-Strings zu kodieren.

  • curses.window hat ein neues Attribut curses.window.encoding.

  • Die Klasse curses.window hat eine neue Methode get_wch(), um ein breites Zeichen zu erhalten.

  • Das Modul curses hat eine neue Funktion unget_wch(), um ein breites Zeichen zu pushen, damit das nächste get_wch() es zurückgibt.

(Beigetragen von Iñigo Serna in bpo-6755.)

datetime

decimal

bpo-7652 - Integration schneller nativer Dezimalarithmetik.

C-Modul und libmpdec, geschrieben von Stefan Krah.

Die neue C-Version des Dezimalmoduls integriert die Hochgeschwindigkeitsbibliothek libmpdec für beliebige Präzisions-, korrekt gerundete Dezimal-Gleitkommaarithmetik. libmpdec entspricht der General Decimal Arithmetic Specification von IBM.

Die Leistungssteigerung reicht von 10x für Datenbankanwendungen bis zu 100x für numerisch intensive Anwendungen. Diese Zahlen sind die erwarteten Gewinne für Standardpräzisionen, die in der Dezimal-Gleitkommaarithmetik verwendet werden. Da die Präzision benutzerkonfigurierbar ist, können die genauen Zahlen variieren. Zum Beispiel können bei Ganzzahl-Bignum-Arithmetik die Unterschiede erheblich höher sein.

Die folgende Tabelle dient zur Veranschaulichung. Benchmarks sind verfügbar unter https://www.bytereef.org/mpdecimal/quickstart.html.

decimal.py

_decimal

Beschleunigung

pi

42.02s

0.345s

120x

telco

172.19s

5.68s

30x

psycopg

3.57s

0.29s

12x

Funktionen

  • Das Signal decimal.FloatOperation ermöglicht optional strengere Semantik für die Mischung von Floats und Decimals.

  • Wenn Python ohne Threads kompiliert wird, deaktiviert die C-Version automatisch die teure, Thread-lokale Kontext-Maschinerie. In diesem Fall wird die Variable HAVE_THREADS auf False gesetzt.

API-Änderungen

  • Das C-Modul hat die folgenden Kontextgrenzen, abhängig von der Maschinenarchitektur

    32-Bit

    64-Bit

    MAX_PREC

    425000000

    999999999999999999

    MAX_EMAX

    425000000

    999999999999999999

    MIN_EMIN

    -425000000

    -999999999999999999

  • In den Kontext-Vorlagen (DefaultContext, BasicContext und ExtendedContext) hat sich die Größenordnung von Emax und Emin zu 999999 geändert.

  • Der Decimal-Konstruktor in decimal.py beachtet die Kontextgrenzen nicht und wandelt Werte mit beliebigen Exponenten oder Genauigkeiten exakt um. Da die C-Version interne Grenzen hat, wird folgendes Schema verwendet: Wenn möglich, werden Werte exakt umgewandelt, andernfalls wird InvalidOperation ausgelöst und das Ergebnis ist NaN. In letzterem Fall ist es immer möglich, create_decimal() zu verwenden, um einen gerundeten oder ungenauen Wert zu erhalten.

  • Die Potenzfunktion in decimal.py ist immer korrekt gerundet. In der C-Version ist sie als korrekt gerundete exp() und ln() Funktionen definiert, aber das Endergebnis ist nur "fast immer korrekt gerundet".

  • In der C-Version ist das Kontext-Dictionary, das die Signale enthält, ein MutableMapping. Aus Geschwindigkeitsgründen verweisen flags und traps immer auf dasselbe MutableMapping, mit dem der Kontext initialisiert wurde. Wenn ein neues Signal-Dictionary zugewiesen wird, werden flags und traps mit den neuen Werten aktualisiert, sie referenzieren jedoch nicht das RHS-Dictionary.

  • Das Pickling eines Context erzeugt eine andere Ausgabe, um ein gemeinsames Austauschformat für die Python- und C-Versionen zu haben.

  • Die Reihenfolge der Argumente im Konstruktor von Context wurde geändert, um der Reihenfolge zu entsprechen, die von repr() angezeigt wird.

  • Der Parameter watchexp in der Methode quantize() ist veraltet.

email

Richtlinien-Framework

Das E-Mail-Paket verfügt nun über ein policy-Framework. Eine Policy ist ein Objekt mit mehreren Methoden und Eigenschaften, die steuern, wie sich das E-Mail-Paket verhält. Die primäre Richtlinie für Python 3.3 ist die Compat32-Richtlinie, die Abwärtskompatibilität mit dem E-Mail-Paket in Python 3.2 bietet. Ein policy kann beim Parsen einer E-Mail-Nachricht durch einen parser, beim Erstellen eines Message-Objekts oder beim Serialisieren einer E-Mail mit einem generator angegeben werden. Sofern nicht überschrieben, wird eine an einen parser übergebene Richtlinie von allen Message-Objekten und Unterobjekten geerbt, die vom parser erstellt werden. Standardmäßig verwendet ein generator die Richtlinie des Message-Objekts, das er serialisiert. Die Standardrichtlinie ist compat32.

Die Mindestsätze von Steuerungen, die von allen policy-Objekten implementiert werden, sind

max_line_length

Die maximale Länge, ohne die Zeilentrennzeichen, die einzelne Zeilen haben dürfen, wenn eine Message serialisiert wird. Standardmäßig 78.

linesep

Das Zeichen, das zur Trennung einzelner Zeilen bei der Serialisierung einer Message verwendet wird. Standardmäßig \n.

cte_type

7bit oder 8bit. 8bit gilt nur für einen Bytes generator und bedeutet, dass Nicht-ASCII-Zeichen dort verwendet werden dürfen, wo es das Protokoll erlaubt (oder wo sie in der ursprünglichen Eingabe vorkommen).

raise_on_defect

Bewirkt, dass ein parser einen Fehler auslöst, wenn Mängel aufgetreten sind, anstatt sie der defects-Liste des Message-Objekts hinzuzufügen.

Eine neue Richtlinieninstanz mit neuen Einstellungen wird mit der Methode clone() von Richtlinienobjekten erstellt. clone nimmt alle oben genannten Steuerungen als Schlüsselwortargumente entgegen. Jede Steuerung, die nicht im Aufruf angegeben wird, behält ihren Standardwert. So können Sie eine Richtlinie erstellen, die \r\n-Zeilentrennzeichen verwendet, wie folgt:

mypolicy = compat32.clone(linesep='\r\n')

Richtlinien können verwendet werden, um die Erstellung von Nachrichten im von Ihrer Anwendung benötigten Format zu vereinfachen. Anstatt sich daran erinnern zu müssen, linesep='\r\n' an allen Stellen anzugeben, an denen Sie einen generator aufrufen, können Sie es einmal angeben, wenn Sie die Richtlinie festlegen, die vom parser oder der Message verwendet wird, je nachdem, was Ihr Programm zum Erstellen von Message-Objekten verwendet. Wenn Sie andererseits Nachrichten in mehreren Formen generieren müssen, können Sie die Parameter immer noch im entsprechenden generator-Aufruf angeben. Oder Sie können benutzerdefinierte Richtlinieninstanzen für Ihre verschiedenen Fälle haben und diese beim Erstellen des generator übergeben.

Provisorische Richtlinie mit neuer Header-API

Obwohl das Richtlinien-Framework an sich lohnenswert ist, ist die Hauptmotivation für seine Einführung die Ermöglichung der Erstellung neuer Richtlinien, die neue Funktionen für das E-Mail-Paket implementieren, und zwar auf eine Weise, die die Abwärtskompatibilität für diejenigen wahren, die die neuen Richtlinien nicht verwenden. Da die neuen Richtlinien eine neue API einführen, werden sie in Python 3.3 als provisorische Richtlinie veröffentlicht. Rückwärts inkompatible Änderungen (einschließlich der Entfernung des Codes) können auftreten, wenn dies von den Kernentwicklern für notwendig erachtet wird.

Die neuen Richtlinien sind Instanzen von EmailPolicy und fügen die folgenden zusätzlichen Steuerungen hinzu:

refold_source

Steuert, ob Header, die von einem parser geparst wurden, vom generator neu umgebrochen werden sollen oder nicht. Kann none, long oder all sein. Standard ist long, was bedeutet, dass Quellheader mit einer Zeile, die länger als max_line_length ist, neu umgebrochen werden. none bedeutet, dass keine Zeile neu umgebrochen wird, und all bedeutet, dass alle Zeilen neu umgebrochen werden.

header_factory

Ein aufrufbares Objekt, das einen name und value entgegennimmt und ein benutzerdefiniertes Header-Objekt erzeugt.

Die header_factory ist der Schlüssel zu den neuen Funktionen, die von den neuen Richtlinien bereitgestellt werden. Wenn eine der neuen Richtlinien verwendet wird, ist jeder Header, der aus einem Message-Objekt abgerufen wird, ein von der header_factory erzeugtes Objekt, und jedes Mal, wenn Sie einen Header auf einem Message setzen, wird er zu einem von der header_factory erzeugten Objekt. Alle solchen Header-Objekte haben ein Attribut name, das dem Header-Namen entspricht. Adress- und Datumsheader haben zusätzliche Attribute, die Ihnen Zugriff auf die geparsten Daten des Headers geben. Das bedeutet, dass Sie jetzt Dinge wie folgt tun können:

>>> m = Message(policy=SMTP)
>>> m['To'] = 'Éric <foo@example.com>'
>>> m['to']
'Éric <foo@example.com>'
>>> m['to'].addresses
(Address(display_name='Éric', username='foo', domain='example.com'),)
>>> m['to'].addresses[0].username
'foo'
>>> m['to'].addresses[0].display_name
'Éric'
>>> m['Date'] = email.utils.localtime()
>>> m['Date'].datetime
datetime.datetime(2012, 5, 25, 21, 39, 24, 465484, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000), 'EDT'))
>>> m['Date']
'Fri, 25 May 2012 21:44:27 -0400'
>>> print(m)
To: =?utf-8?q?=C3=89ric?= <foo@example.com>
Date: Fri, 25 May 2012 21:44:27 -0400

Sie werden feststellen, dass der Unicode-Anzeigename automatisch als utf-8 kodiert wird, wenn die Nachricht serialisiert wird, aber wenn auf den Header direkt zugegriffen wird, erhalten Sie die Unicode-Version. Dies beseitigt die Notwendigkeit, mit den Funktionen email.header decode_header() oder make_header() zu arbeiten.

Sie können auch Adressen aus Teilen erstellen

>>> m['cc'] = [Group('pals', [Address('Bob', 'bob', 'example.com'),
...                           Address('Sally', 'sally', 'example.com')]),
...            Address('Bonzo', addr_spec='bonz@laugh.com')]
>>> print(m)
To: =?utf-8?q?=C3=89ric?= <foo@example.com>
Date: Fri, 25 May 2012 21:44:27 -0400
cc: pals: Bob <bob@example.com>, Sally <sally@example.com>;, Bonzo <bonz@laugh.com>

Die Dekodierung nach Unicode erfolgt automatisch

>>> m2 = message_from_string(str(m))
>>> m2['to']
'Éric <foo@example.com>'

Wenn Sie eine Nachricht parsen, können Sie die Attribute addresses und groups der Header-Objekte verwenden, um auf die Gruppen und einzelnen Adressen zuzugreifen

>>> m2['cc'].addresses
(Address(display_name='Bob', username='bob', domain='example.com'), Address(display_name='Sally', username='sally', domain='example.com'), Address(display_name='Bonzo', username='bonz', domain='laugh.com'))
>>> m2['cc'].groups
(Group(display_name='pals', addresses=(Address(display_name='Bob', username='bob', domain='example.com'), Address(display_name='Sally', username='sally', domain='example.com')), Group(display_name=None, addresses=(Address(display_name='Bonzo', username='bonz', domain='laugh.com'),))

Zusammenfassend lässt sich sagen, dass die Header-Manipulation so funktioniert, wie sie sollte, wenn Sie eine der neuen Richtlinien verwenden: Ihre Anwendung arbeitet mit Unicode-Strings, und das E-Mail-Paket kodiert und dekodiert Unicode transparent in und aus den RFC-konformen Content Transfer Encodings.

Weitere API-Änderungen

Neuer BytesHeaderParser, hinzugefügt zum Modul parser, um HeaderParser zu ergänzen und die Bytes-API zu vervollständigen.

Neue Hilfsfunktionen

ftplib

  • ftplib.FTP akzeptiert jetzt ein Schlüsselwortargument source_address, um die zu verwendende (host, port) als Quelladresse im Bind-Aufruf beim Erstellen des ausgehenden Sockets anzugeben. (Beigetragen von Giampaolo Rodolà in bpo-8594.)

  • Die Klasse FTP_TLS bietet nun eine neue Funktion ccc(), um den Steuerkanal wieder in Klartext umzuwandeln. Dies kann nützlich sein, um Firewalls zu nutzen, die NAT mit nicht-sicherem FTP ohne Öffnen fester Ports handhaben können. (Beigetragen von Giampaolo Rodolà in bpo-12139.)

  • Die Methode ftplib.FTP.mlsd() wurde hinzugefügt, die ein parsbares Verzeichnislistenformat bereitstellt und ftplib.FTP.nlst() und ftplib.FTP.dir() als veraltet kennzeichnet. (Beigetragen von Giampaolo Rodolà in bpo-11072.)

functools

Der Dekorator functools.lru_cache() akzeptiert jetzt ein Schlüsselwortargument typed (das standardmäßig False ist), um sicherzustellen, dass Werte unterschiedlicher Typen, die gleich verglichen werden, in separaten Cache-Slots gespeichert werden. (Beigetragen von Raymond Hettinger in bpo-13227.)

gc

Es ist nun möglich, Rückrufe zu registrieren, die vom Garbage Collector vor und nach der Sammlung aufgerufen werden, indem die neue Liste callbacks verwendet wird.

hmac

Eine neue Funktion compare_digest() wurde hinzugefügt, um Side-Channel-Angriffe auf Digests durch Timing-Analyse zu verhindern. (Beigetragen von Nick Coghlan und Christian Heimes in bpo-15061.)

http

http.server.BaseHTTPRequestHandler puffert nun die Header und schreibt sie alle auf einmal, wenn end_headers() aufgerufen wird. Eine neue Methode flush_headers() kann verwendet werden, um zu steuern, wann die angesammelten Header gesendet werden. (Beigetragen von Andrew Schaaf in bpo-3709.)

Die Ausgabe von http.server ist nun gültiges HTML 4.01 strict. (Beigetragen von Ezio Melotti in bpo-13295.)

http.client.HTTPResponse hat jetzt eine Methode readinto(), was bedeutet, dass sie als io.RawIOBase-Klasse verwendet werden kann. (Beigetragen von John Kuhn in bpo-13464.)

html

html.parser.HTMLParser kann nun fehlerhaften Markup parsen, ohne Fehler auszulösen. Daher sind das Argument strict des Konstruktors und die Ausnahme HTMLParseError nun veraltet. Die Fähigkeit, fehlerhaften Markup zu parsen, ist das Ergebnis einer Reihe von Fehlerbehebungen, die auch in den neuesten Bugfix-Releases von Python 2.7/3.2 verfügbar sind. (Beigetragen von Ezio Melotti in bpo-15114 und bpo-14538, bpo-13993, bpo-13960, bpo-13358, bpo-1745761, bpo-755670, bpo-13357, bpo-12629, bpo-1200313, bpo-670664, bpo-13273, bpo-12888, bpo-7311.)

Ein neues Dictionary html5, das HTML5-benannte Zeichenreferenzen auf die entsprechenden Unicode-Zeichen abbildet (z. B. html5['gt;'] == '>'), wurde dem Modul html.entities hinzugefügt. Das Dictionary wird nun auch von HTMLParser verwendet. (Beigetragen von Ezio Melotti in bpo-11113 und bpo-15156.)

imaplib

Der Konstruktor von IMAP4_SSL akzeptiert nun einen SSLContext-Parameter zur Steuerung der Parameter des sicheren Kanals.

(Beigetragen von Sijin Joseph in bpo-8808.)

inspect

Eine neue Funktion getclosurevars() wurde hinzugefügt. Diese Funktion meldet die aktuelle Bindung aller im Funktionskörper referenzierten Namen und wo diese Namen aufgelöst wurden, was die Überprüfung des korrekten internen Zustands bei der Prüfung von Code, der zustandsabhängige Closures verwendet, erleichtert.

(Beigetragen von Meador Inge und Nick Coghlan in bpo-13062.)

Eine neue Funktion getgeneratorlocals() wurde hinzugefügt. Diese Funktion meldet die aktuelle Bindung von lokalen Variablen im Stack-Frame des Generators, was die Überprüfung des korrekten internen Zustands bei der Prüfung von Generatoren erleichtert.

(Beigetragen von Meador Inge in bpo-15153.)

io

Die Funktion open() hat einen neuen Modus 'x', der verwendet werden kann, um eine neue Datei exklusiv zu erstellen und eine FileExistsError auszulösen, wenn die Datei bereits existiert. Er basiert auf dem C11 'x'-Modus für fopen().

(Beigetragen von David Townshend in bpo-12760.)

Der Konstruktor der Klasse TextIOWrapper hat ein neues optionales Argument write_through. Wenn write_through auf True gesetzt ist, wird garantiert, dass Aufrufe von write() nicht gepuffert werden: Alle Daten, die auf dem TextIOWrapper-Objekt geschrieben werden, werden sofort an seinen zugrunde liegenden Binärpuffer übergeben.

itertools

accumulate() nimmt nun ein optionales Argument func für die Bereitstellung einer benutzerdefinierten binären Funktion entgegen.

logging

Die Funktion basicConfig() unterstützt nun ein optionales Argument handlers, das ein Iterable von Handlern entgegennimmt, die dem Root-Logger hinzugefügt werden.

Ein Klassenattribut append_nul wurde zu SysLogHandler hinzugefügt, um die Anhängung des NUL-Bytes (\000) an Syslog-Einträge zu steuern, da dies für einige Daemons erforderlich ist, für andere jedoch an das Log weitergegeben wird.

math

Das Modul math hat eine neue Funktion, log2(), die den Basis-2-Logarithmus von x zurückgibt.

(Geschrieben von Mark Dickinson in bpo-11888.)

mmap

Die Methode read() ist nun besser mit anderen dateiähnlichen Objekten kompatibel: Wenn das Argument weggelassen oder als None angegeben wird, gibt sie die Bytes vom aktuellen Dateizeiger bis zum Ende des Mappings zurück. (Beigetragen von Petri Lehtinen in bpo-12021.)

multiprocessing

Die neue Funktion multiprocessing.connection.wait() ermöglicht das Abfragen mehrerer Objekte (wie Verbindungen, Sockets und Pipes) mit einem Timeout. (Beigetragen von Richard Oudkerk in bpo-12328.)

multiprocessing.connection.Connection-Objekte können nun über Multiprocessing-Verbindungen übertragen werden. (Beigetragen von Richard Oudkerk in bpo-4892.)

Die Klasse multiprocessing.Process akzeptiert nun das Schlüsselwortargument daemon, um das Standardverhalten zu überschreiben, das das daemon-Flag vom Elternprozess erbt (bpo-6064).

Das neue Attribut multiprocessing.Process.sentinel ermöglicht es einem Programm, gleichzeitig auf mehrere Process-Objekte zu warten, indem die entsprechenden Betriebssystem-Primitiven verwendet werden (z. B. select auf POSIX-Systemen).

Neue Methoden multiprocessing.pool.Pool.starmap() und starmap_async() bieten itertools.starmap()-Entsprechungen zu den bestehenden multiprocessing.pool.Pool.map() und map_async() Funktionen. (Beigetragen von Hynek Schlawack in bpo-12708.)

nntplib

Die Klasse nntplib.NNTP unterstützt jetzt das Kontextmanagementprotokoll, um socket.error-Ausnahmen bedingungslos zu verarbeiten und die NNTP-Verbindung bei Abschluss zu schließen.

>>> from nntplib import NNTP
>>> with NNTP('news.gmane.org') as n:
...     n.group('gmane.comp.python.committers')
...
('211 1755 1 1755 gmane.comp.python.committers', 1755, 1, 1755, 'gmane.comp.python.committers')
>>>

(Beigetragen von Giampaolo Rodolà in bpo-9795.)

os

  • Das Modul os verfügt über die neue Funktion pipe2(), die es ermöglicht, eine Pipe mit gesetzten Flags O_CLOEXEC oder O_NONBLOCK atomar zu erstellen. Dies ist besonders nützlich, um Race Conditions in Multithread-Programmen zu vermeiden.

  • Das Modul os verfügt über die neue Funktion sendfile(), die eine effiziente "Zero-Copy"-Methode zum Kopieren von Daten von einem Dateideskriptor (oder Socket) zu einem anderen bietet. Der Ausdruck "Zero-Copy" bezieht sich darauf, dass das gesamte Kopieren von Daten zwischen den beiden Deskriptoren vollständig vom Kernel übernommen wird, ohne dass Daten in User-Space-Puffer kopiert werden. sendfile() kann verwendet werden, um Daten effizient von einer Festplattendatei an einen Netzwerksocket zu kopieren, z. B. zum Herunterladen einer Datei.

    (Patch eingereicht von Ross Lagerwall und Giampaolo Rodolà in bpo-10882.)

  • Um Race Conditions wie Symlink-Angriffe und Probleme mit temporären Dateien und Verzeichnissen zu vermeiden, ist es zuverlässiger (und auch schneller), mit Dateideskriptoren anstatt mit Dateinamen zu arbeiten. Python 3.3 verbessert bestehende Funktionen und führt neue Funktionen ein, um mit Dateideskriptoren zu arbeiten (bpo-4761, bpo-10755 und bpo-14626).

  • access() akzeptiert ein Schlüsselwortargument effective_ids, um die Verwendung der effektiven uid/gid anstelle der realen uid/gid in der Zugriffsprüfung zu aktivieren. Die Plattformunterstützung dafür kann über die Menge supports_effective_ids geprüft werden.

  • Das Modul os hat zwei neue Funktionen: getpriority() und setpriority(). Sie können verwendet werden, um die niceness/priority von Prozessen ähnlich wie os.nice() abzurufen oder festzulegen, erweitert auf alle Prozesse statt nur auf den aktuellen.

    (Patch eingereicht von Giampaolo Rodolà in bpo-10784.)

  • Die neue Funktion os.replace() ermöglicht plattformübergreifendes Umbenennen einer Datei, wobei das Ziel überschrieben wird. Mit os.rename() wird eine vorhandene Zieldatei unter POSIX überschrieben, unter Windows wird jedoch ein Fehler ausgelöst. (Beigetragen von Antoine Pitrou in bpo-8828.)

  • Die Funktionen der `stat`-Familie (stat(), fstat() und lstat()) unterstützen nun das Lesen von Dateizeitstempeln mit Nanosekundenpräzision. Symmetrisch kann utime() nun auch Dateizeitstempel mit Nanosekundenpräzision schreiben. (Beigetragen von Larry Hastings in bpo-14127.)

  • Die neue Funktion os.get_terminal_size() fragt die Größe des Terminals ab, das an einen Dateideskriptor angehängt ist. Siehe auch shutil.get_terminal_size(). (Beigetragen von Zbigniew Jędrzejewski-Szmek in bpo-13609.)

pdb

Tab-Vervollständigung ist nun nicht nur für Befehlsnamen, sondern auch für deren Argumente verfügbar. Zum Beispiel werden für den Befehl break Funktions- und Dateinamen vervollständigt.

(Beigetragen von Georg Brandl in bpo-14210)

pickle

pickle.Pickler-Objekte haben nun ein optionales Attribut dispatch_table, das die Festlegung von Reduktionsfunktionen pro Pickler ermöglicht.

(Beigetragen von Richard Oudkerk in bpo-14166.)

pydoc

Die Tk-GUI und die Funktion serve() wurden aus dem Modul pydoc entfernt: pydoc -g und serve() wurden in Python 3.2 als veraltet markiert.

re

Reguläre Ausdrücke für str unterstützen nun die Escape-Sequenzen \u und \U.

(Beigetragen von Serhiy Storchaka in bpo-3665.)

sched

  • Die Methode run() akzeptiert nun einen Parameter blocking, der, wenn er auf false gesetzt ist, bewirkt, dass die Methode die nächst fälligen geplanten Ereignisse (falls vorhanden) ausführt und dann sofort zurückkehrt. Dies ist nützlich, wenn Sie den scheduler in nicht blockierenden Anwendungen verwenden möchten. (Beigetragen von Giampaolo Rodolà in bpo-13449.)

  • Die Klasse scheduler kann nun sicher in Multithread-Umgebungen verwendet werden. (Beigetragen von Josiah Carlson und Giampaolo Rodolà in bpo-8684.)

  • Die Parameter timefunc und delayfunct des Konstruktors der Klasse scheduler sind nun optional und verwenden standardmäßig time.time() bzw. time.sleep(). (Beigetragen von Chris Clark in bpo-13245.)

  • Der Parameter argument der Methoden enter() und enterabs() ist nun optional. (Beigetragen von Chris Clark in bpo-13245.)

  • enter() und enterabs() akzeptieren nun einen Parameter kwargs. (Beigetragen von Chris Clark in bpo-13245.)

select

Solaris und abgeleitete Plattformen verfügen über die neue Klasse select.devpoll für hochperformante asynchrone Sockets über /dev/poll. (Beigetragen von Jesús Cea Avión in bpo-6397.)

shlex

Die zuvor undokumentierte Hilfsfunktion quote aus dem Modul pipes wurde in das Modul shlex verschoben und dokumentiert. quote() maskiert ordnungsgemäß alle Zeichen in einem String, die von der Shell sonst eine besondere Bedeutung erhalten könnten.

shutil

  • Neue Funktionen

    • disk_usage(): Liefert Statistiken über den gesamten, genutzten und freien Speicherplatz auf der Festplatte. (Beigetragen von Giampaolo Rodolà in bpo-12442.)

    • chown(): Ermöglicht das Ändern des Benutzers und/oder der Gruppe eines Pfades, wobei auch Benutzernamen und Gruppennamen anstelle von nur numerischen IDs angegeben werden können. (Beigetragen von Sandro Tosi in bpo-12191.)

    • shutil.get_terminal_size(): Gibt die Größe des Terminalfensters zurück, an das der Interpreter angeschlossen ist. (Beigetragen von Zbigniew Jędrzejewski-Szmek in bpo-13609.)

  • copy2() und copystat() erhalten nun Dateizeitstempel mit Nanosekundenpräzision auf unterstützten Plattformen. Sie erhalten auch "erweiterte Attribute" von Dateien unter Linux. (Beigetragen von Larry Hastings in bpo-14127 und bpo-15238.)

  • Mehrere Funktionen nehmen nun ein optionales Argument symlinks entgegen: Wenn dieser Parameter true ist, werden Symlinks nicht dereferenziert und die Operation wirkt stattdessen auf den Symlink selbst (oder erstellt einen, falls relevant). (Beigetragen von Hynek Schlawack in bpo-12715.)

  • Beim Kopieren von Dateien auf ein anderes Dateisystem behandelt move() Symlinks jetzt so, wie der POSIX-Befehl mv dies tut, und erstellt den Symlink neu anstatt den Inhalt der Zieldatei zu kopieren. (Beigetragen von Jonathan Niehof in bpo-9993.) move() gibt nun auch das Argument dst als Ergebnis zurück.

  • rmtree() ist nun resistent gegen Symlink-Angriffe auf Plattformen, die den neuen Parameter dir_fd in os.open() und os.unlink() unterstützen. (Beigetragen von Martin von Löwis und Hynek Schlawack in bpo-4489.)

signal

  • Das Modul signal hat neue Funktionen

  • Der Signal-Handler schreibt die Signalnummer als einzelnes Byte anstelle eines Null-Bytes in den Wakeup-Deskriptor. So ist es möglich, auf mehrere Signale zu warten und zu wissen, welche Signale ausgelöst wurden.

  • signal.signal() und signal.siginterrupt() lösen eine OSError aus, anstatt einer RuntimeError: OSError hat ein errno-Attribut.

smtpd

Das Modul smtpd unterstützt jetzt RFC 5321 (Extended SMTP) und RFC 1870 (SIZE-Erweiterung). Gemäß dem Standard sind diese Erweiterungen genau dann aktiviert, wenn der Client die Sitzung mit einem EHLO-Befehl initiiert.

(Ursprüngliche ELHO-Unterstützung von Alberto Trevino. SIZE-Erweiterung von Juhana Jauhiainen. Umfangreiche zusätzliche Arbeit am Patch von Michele Orrù und Dan Boswell. bpo-8739)

smtplib

Die Klassen SMTP, SMTP_SSL und LMTP akzeptieren nun ein Schlüsselwortargument source_address, um die (host, port) anzugeben, die bei der Erstellung des ausgehenden Sockets für den Bind-Aufruf als Quelladresse verwendet werden soll. (Beigetragen von Paulo Scardine in bpo-11281.)

SMTP unterstützt nun das Context-Management-Protokoll, wodurch eine SMTP-Instanz in einer with-Anweisung verwendet werden kann. (Beigetragen von Giampaolo Rodolà in bpo-11289.)

Der Konstruktor von SMTP_SSL und die Methode starttls() akzeptieren nun einen SSLContext-Parameter zur Steuerung von Parametern des sicheren Kanals. (Beigetragen von Kasun Herath in bpo-8809.)

socket

socketserver

BaseServer hat nun eine überschreibbare Methode service_actions(), die von der Methode serve_forever() in der Service-Schleife aufgerufen wird. ForkingMixIn nutzt dies nun, um Zombie-Kindprozesse aufzuräumen. (Beigetragen von Justin Warkentin in bpo-11109.)

sqlite3

Die neue Methode sqlite3.Connection set_trace_callback() kann verwendet werden, um einen Trace aller von SQLite verarbeiteten SQL-Befehle zu erfassen. (Beigetragen von Torsten Landschoff in bpo-11688.)

ssl

  • Das Modul ssl hat zwei neue Funktionen zur Zufallsgenerierung

    • RAND_bytes(): erzeugt kryptographisch starke pseudozufällige Bytes.

    • RAND_pseudo_bytes(): erzeugt pseudozufällige Bytes.

    (Beigetragen von Victor Stinner in bpo-12049.)

  • Das Modul ssl stellt nun eine feinere Ausnahmehierarchie zur Verfügung, um die verschiedenen Fehlerarten leichter inspizieren zu können. (Beigetragen von Antoine Pitrou in bpo-11183.)

  • load_cert_chain() akzeptiert nun ein Argument password, das verwendet wird, wenn der private Schlüssel verschlüsselt ist. (Beigetragen von Adam Simpkins in bpo-12803.)

  • Diffie-Hellman-Schlüsselaustausch, sowohl regulär als auch auf Elliptischen Kurven basierend, wird nun durch die Methoden load_dh_params() und set_ecdh_curve() unterstützt. (Beigetragen von Antoine Pitrou in bpo-13626 und bpo-13627.)

  • SSL-Sockets haben eine neue Methode get_channel_binding(), die die Implementierung bestimmter Authentifizierungsmechanismen wie SCRAM-SHA-1-PLUS ermöglicht. (Beigetragen von Jacek Konieczny in bpo-12551.)

  • Der von einem SSL-Socket verwendete SSL-Kompressionsalgorithmus kann dank seiner neuen Methode compression() abgefragt werden. Das neue Attribut OP_NO_COMPRESSION kann verwendet werden, um die Komprimierung zu deaktivieren. (Beigetragen von Antoine Pitrou in bpo-13634.)

  • Die Unterstützung für die Next Protocol Negotiation (NPN)-Erweiterung wurde durch die Methode ssl.SSLContext.set_npn_protocols() hinzugefügt. (Beigetragen von Colin Marc in bpo-14204.)

  • SSL-Fehler können nun dank der Attribute library und reason einfacher introspektiert werden. (Beigetragen von Antoine Pitrou in bpo-14837.)

  • Die Funktion get_server_certificate() unterstützt nun IPv6. (Beigetragen von Charles-François Natali in bpo-11811.)

  • Das neue Attribut OP_CIPHER_SERVER_PREFERENCE ermöglicht es, SSLv3-Server-Sockets so einzustellen, dass die bevorzugte Cipher-Reihenfolge des Servers anstelle der des Clients verwendet wird (bpo-13635).

stat

Die undokumentierte Funktion tarfile.filemode wurde nach stat.filemode() verschoben. Sie kann verwendet werden, um den Modus einer Datei in einen String der Form '-rwxrwxrwx' umzuwandeln.

(Beigetragen von Giampaolo Rodolà in bpo-14807.)

struct

Das Modul struct unterstützt nun ssize_t und size_t über die neuen Codes n und N. (Beigetragen von Antoine Pitrou in bpo-3163.)

subprocess

Befehlsstrings können unter POSIX-Plattformen nun Byte-Objekte sein. (Beigetragen von Victor Stinner in bpo-8513.)

Eine neue Konstante DEVNULL ermöglicht die plattformunabhängige Unterdrückung der Ausgabe. (Beigetragen von Ross Lagerwall in bpo-5870.)

sys

Das Modul sys hat ein neues named tuple thread_info, das Informationen über die Thread-Implementierung enthält (bpo-11223).

tarfile

tarfile unterstützt nun die lzma-Kodierung über das Modul lzma. (Beigetragen von Lars Gustäbel in bpo-5689.)

tempfile

Die Methode truncate() von tempfile.SpooledTemporaryFile akzeptiert nun einen Parameter size. (Beigetragen von Ryan Kelly in bpo-9957.)

textwrap

Das Modul textwrap hat eine neue Funktion indent(), die es einfach macht, ausgewählten Zeilen in einem Textblock ein gemeinsames Präfix hinzuzufügen (bpo-13857).

threading

threading.Condition, threading.Semaphore, threading.BoundedSemaphore, threading.Event und threading.Timer, die alle früher Factory-Funktionen waren, die eine Klasseninstanz zurückgaben, sind nun Klassen und können Unterklassen bilden. (Beigetragen von Éric Araujo in bpo-10968.)

Der Konstruktor von threading.Thread akzeptiert nun ein Schlüsselwortargument daemon, um das Standardverhalten des Erbrechens des daemon-Flags vom Eltern-Thread zu überschreiben (bpo-6064).

Die ehemals private Funktion _thread.get_ident ist nun als öffentliche Funktion threading.get_ident() verfügbar. Dies eliminiert mehrere Fälle des direkten Zugriffs auf das Modul _thread in der Standardbibliothek. Drittanbieter-Code, der _thread.get_ident verwendet hat, sollte ebenfalls geändert werden, um die neue öffentliche Schnittstelle zu verwenden.

time

Das PEP 418 fügte dem Modul time neue Funktionen hinzu

  • get_clock_info(): Liefert Informationen über eine Uhr.

  • monotonic(): Monotone Uhr (kann nicht rückwärts laufen), wird von Systemuhr-Updates nicht beeinflusst.

  • perf_counter(): Performance-Zähler mit der höchstmöglichen Auflösung zur Messung kurzer Dauern.

  • process_time(): Summe der System- und Benutzer-CPU-Zeit des aktuellen Prozesses.

Weitere neue Funktionen

Zur Verbesserung der plattformübergreifenden Konsistenz löst sleep() nun einen ValueError aus, wenn ein negativer Schlaf-Wert übergeben wird. Zuvor war dies unter POSIX ein Fehler, führte aber unter Windows zu einem unendlichen Schlaf.

types

Neue Klasse types.MappingProxyType: Schreibgeschützter Proxy für ein Mapping. (bpo-14386)

Die neuen Funktionen types.new_class() und types.prepare_class() bieten Unterstützung für die PEP 3115-konforme dynamische Erzeugung von Typen. (bpo-14588)

unittest

assertRaises(), assertRaisesRegex(), assertWarns() und assertWarnsRegex() akzeptieren nun ein Schlüsselwortargument msg, wenn sie als Kontextmanager verwendet werden. (Beigetragen von Ezio Melotti und Winston Ewert in bpo-10775.)

unittest.TestCase.run() gibt nun das Objekt TestResult zurück.

urllib

Die Klasse Request akzeptiert nun ein Argument method, das von get_method() verwendet wird, um zu bestimmen, welche HTTP-Methode verwendet werden soll. Zum Beispiel wird damit eine 'HEAD'-Anfrage gesendet

>>> urlopen(Request('https://pythonlang.de', method='HEAD'))

(bpo-1673007)

webbrowser

Das Modul webbrowser unterstützt mehr "Browser": Google Chrome (benannt chrome, chromium, chrome-browser oder chromium-browser je nach Version und Betriebssystem) und die generischen Launcher xdg-open vom FreeDesktop.org-Projekt und gvfs-open, den Standard-URI-Handler für GNOME 3. (Ersteres beigetragen von Arnaud Calmettes in bpo-13620, letzteres von Matthias Klose in bpo-14493.)

xml.etree.ElementTree

Das Modul xml.etree.ElementTree importiert nun standardmäßig seinen C-Beschleuniger; es ist nicht mehr notwendig, explizit xml.etree.cElementTree zu importieren (dieses Modul bleibt aus Gründen der Abwärtskompatibilität erhalten, ist aber nun veraltet). Außerdem wurden die Methoden der iter-Familie von Element optimiert (in C neu geschrieben). Die Dokumentation des Moduls wurde ebenfalls erheblich verbessert und mit zusätzlichen Beispielen und einem detaillierteren Verzeichnis versehen.

zlib

Das neue Attribut zlib.Decompress.eof ermöglicht es, zwischen einem korrekt gebildeten komprimierten Stream und einem unvollständigen oder abgeschnittenen Stream zu unterscheiden. (Beigetragen von Nadeem Vawda in bpo-12646.)

Das neue Attribut zlib.ZLIB_RUNTIME_VERSION meldet die Versionszeichenfolge der zugrunde liegenden zlib-Bibliothek, die zur Laufzeit geladen wird. (Beigetragen von Torsten Landschoff in bpo-12306.)

Optimierungen

Wesentliche Leistungsverbesserungen wurden vorgenommen

  • Dank PEP 393 wurden einige Operationen auf Unicode-Strings optimiert

    • der Speicherbedarf wird je nach Text um das 2- bis 4-fache reduziert

    • die Kodierung eines ASCII-Strings nach UTF-8 erfordert keine weitere Kodierung mehr, die UTF-8-Darstellung wird mit der ASCII-Darstellung geteilt

    • der UTF-8-Encoder wurde optimiert

    • das Wiederholen eines einzelnen ASCII-Buchstabens und das Erhalten eines Teilstrings eines ASCII-Strings ist 4x schneller

  • UTF-8 ist jetzt 2x bis 4x schneller. UTF-16-Kodierung ist jetzt bis zu 10x schneller.

    (Beigetragen von Serhiy Storchaka, bpo-14624, bpo-14738 und bpo-15026.)

Build- und C-API-Änderungen

Änderungen am Build-Prozess von Python und an der C-API umfassen

Veraltet

Nicht unterstützte Betriebssysteme

OS/2 und VMS werden aufgrund mangelnder Wartung nicht mehr unterstützt.

Windows 2000 und Windows-Plattformen, die COMSPEC auf command.com setzen, werden aus Wartungsgründen nicht mehr unterstützt.

Die OSF-Unterstützung, die in 3.2 veraltet war, wurde vollständig entfernt.

Veraltete Python-Module, Funktionen und Methoden

Veraltete Funktionen und Typen der C-API

Der Typ Py_UNICODE wurde durch PEP 393 als veraltet markiert und wird in Python 4 entfernt. Alle Funktionen, die diesen Typ verwenden, sind veraltet.

Unicode-Funktionen und -Methoden, die Py_UNICODE und Py_UNICODE*-Typen verwenden

Funktionen und Makros zur Bearbeitung von Py_UNICODE* Zeichenketten

Encoder

Veraltete Funktionen

Der Formatcode 'u' des array-Moduls ist nun veraltet und wird zusammen mit der übrigen (Py_UNICODE) API in Python 4 entfernt.

Portierung auf Python 3.3

Dieser Abschnitt listet zuvor beschriebene Änderungen und weitere Fehlerbehebungen auf, die möglicherweise Änderungen an Ihrem Code erfordern.

Portierung von Python-Code

  • Hash-Randomisierung ist standardmäßig aktiviert. Setzen Sie die Umgebungsvariable PYTHONHASHSEED auf 0, um die Hash-Randomisierung zu deaktivieren. Siehe auch die Methode object.__hash__().

  • bpo-12326: Unter Linux enthält `sys.platform` nicht mehr die Hauptversion. Es ist nun immer 'linux' statt 'linux2' oder 'linux3', je nach der Linux-Version, mit der Python kompiliert wurde. Ersetzen Sie `sys.platform == 'linux2'` durch `sys.platform.startswith('linux')` oder direkt `sys.platform == 'linux'`, wenn Sie ältere Python-Versionen nicht unterstützen müssen.

  • bpo-13847, bpo-14180: In `time` und `datetime` wird nun ein OverflowError statt eines ValueError ausgelöst, wenn ein Zeitstempel außerhalb des gültigen Bereichs liegt. Ein OSError wird nun ausgelöst, wenn die C-Funktionen gmtime() oder localtime() fehlschlagen.

  • Die von import standardmäßig verwendeten Finder nutzen nun einen Cache für den Inhalt eines bestimmten Verzeichnisses. Wenn Sie eine Python-Quelldatei oder eine Bytecode-Datei ohne Quellcode erstellen, stellen Sie sicher, dass Sie importlib.invalidate_caches() aufrufen, um den Cache für die Finder zu leeren, damit diese die neue Datei erkennen.

  • ImportError verwendet nun den vollständigen Namen des versuchten Moduls. Doctests, die die Meldung von ImportErrors überprüfen, müssen aktualisiert werden, um den vollständigen Modulnamen anstelle des Schwanzes des Namens zu verwenden.

  • Das Argument index für __import__() hat nun standardmäßig den Wert 0 statt -1 und unterstützt keine negativen Werte mehr. Es war ein Versehen bei der Implementierung von PEP 328, dass der Standardwert -1 geblieben ist. Wenn Sie weiterhin einen relativen Import gefolgt von einem absoluten Import durchführen müssen, führen Sie den relativen Import mit dem Index 1 durch, gefolgt von einem weiteren Import mit dem Index 0. Es ist jedoch vorzuziehen, importlib.import_module() zu verwenden, anstatt __import__() direkt aufzurufen.

  • __import__() erlaubt es nicht mehr, einen Indexwert außer 0 für Top-Level-Module zu verwenden. Zum Beispiel ist __import__('sys', level=1) nun ein Fehler.

  • Da `sys.meta_path` und `sys.path_hooks` standardmäßig Finder enthalten, werden Sie wahrscheinlich `list.insert()` anstelle von `list.append()` verwenden wollen, um Elemente zu diesen Listen hinzuzufügen.

  • Da `None` nun in `sys.path_importer_cache` eingefügt wird, müssen Sie, wenn Sie Einträge im Wörterbuch von Pfaden ohne Finder leeren, Schlüssel entfernen, die mit Werten von `None` *und* `imp.NullImporter` gepaart sind, um abwärtskompatibel zu sein. Dies führt zu zusätzlichem Overhead bei älteren Python-Versionen, die `None` wieder in `sys.path_importer_cache` einfügen, wo es die Verwendung impliziter Finder darstellt, aber semantisch sollte es nichts ändern.

  • `importlib.abc.Finder` gibt keine `find_module()` abstrakte Methode mehr vor, die implementiert werden muss. Wenn Sie sich darauf verlassen haben, dass Unterklassen diese Methode implementieren, stellen Sie sicher, dass Sie zuerst auf die Existenz der Methode prüfen. Wahrscheinlich möchten Sie jedoch zuerst nach `find_loader()` suchen, wenn Sie mit Pfad-Einstiegs-Findern arbeiten.

  • pkgutil wurde intern auf die Verwendung von importlib umgestellt. Dies eliminiert viele Grenzfälle, in denen das alte Verhalten der PEP 302 Import-Emulation nicht mit dem Verhalten des echten Importsystems übereinstimmte. Die Import-Emulation selbst ist noch vorhanden, aber nun veraltet. Die Funktionen pkgutil.iter_importers() und pkgutil.walk_packages() behandeln die Standard-Import-Hooks gesondert, sodass diese weiterhin unterstützt werden, obwohl sie nicht die nicht standardmäßige Methode `iter_modules()` bereitstellen.

  • Ein seit langem bestehender RFC-konformer Fehler (bpo-1079) in der von email.header.decode_header() durchgeführten Parsierung wurde behoben. Code, der das Standardidiom zur Konvertierung kodierter Header in Unicode verwendet (`str(make_header(decode_header(h)))`), wird keine Änderung feststellen, aber Code, der die von decode_header zurückgegebenen einzelnen Tupel betrachtet, wird feststellen, dass Whitespace vor oder nach ASCII-Abschnitten nun im ASCII-Abschnitt enthalten ist. Code, der Header mit `make_header` erstellt, sollte ebenfalls ohne Änderungen funktionieren, da `make_header` weiterhin Whitespace zwischen ASCII- und Nicht-ASCII-Abschnitten hinzufügt, wenn dieser nicht bereits in den Eingabezeichenketten vorhanden ist.

  • email.utils.formataddr() führt nun die korrekte Content-Transfer-Codierung durch, wenn nicht-ASCII-Anzeigenamen übergeben werden. Jeglicher Code, der vom vorherigen fehlerhaften Verhalten abhing, das nicht-ASCII-Unicode in der formatierten Ausgabenzeichenkette beibehielt, muss geändert werden (bpo-1690608).

  • poplib.POP3.quit() kann nun Protokollfehler auslösen, wie alle anderen `poplib`-Methoden. Code, der annimmt, dass `quit` keine `poplib.error_proto`-Fehler auslöst, muss möglicherweise geändert werden, wenn Fehler bei `quit` von einer bestimmten Anwendung angetroffen werden (bpo-11291).

  • Das Argument `strict` für email.parser.Parser, das seit Python 2.4 veraltet war, wurde schließlich entfernt.

  • Die veraltete Methode unittest.TestCase.assertSameElements wurde entfernt.

  • Die veraltete Variable time.accept2dyear wurde entfernt.

  • Das veraltete Attribut `Context._clamp` wurde aus dem decimal-Modul entfernt. Es wurde zuvor durch das öffentliche Attribut clamp ersetzt. (Siehe bpo-8540.)

  • Die undokumentierte interne Hilfsklasse `SSLFakeFile` wurde aus smtplib entfernt, da ihre Funktionalität seit langem direkt von socket.socket.makefile() bereitgestellt wird.

  • Das Übergeben eines negativen Wertes an `time.sleep()` unter Windows löst nun einen Fehler aus, anstatt ewig zu schlafen. Unter POSIX wurde immer ein Fehler ausgelöst.

  • Die Konstante `ast.__version__` wurde entfernt. Wenn Sie Entscheidungen treffen müssen, die von der AST-Version abhängen, verwenden Sie `sys.version_info`, um die Entscheidung zu treffen.

  • Code, der früher die Tatsache ausnutzte, dass das threading-Modul Factory-Funktionen durch Unterklassenbildung der privaten Klassen verwendete, muss geändert werden, um die nun öffentlichen Klassen zu unterklassen.

  • Die undokumentierte Debugging-Mechanik im Threading-Modul wurde entfernt, was den Code vereinfacht. Dies sollte keine Auswirkungen auf Produktionscode haben, wird aber hier erwähnt, falls sich Anwendungs-Debug-Frameworks damit beschäftigt haben (bpo-13550).

Portierung von C-Code

  • Im Zuge von Änderungen an der Buffer-API wurde das undokumentierte `smalltable`-Mitglied der `Py_buffer`-Struktur entfernt und das Layout des `PyMemoryViewObject` geändert.

    Alle Erweiterungen, die sich auf die entsprechenden Teile in `memoryobject.h` oder `object.h` verlassen, müssen neu kompiliert werden.

  • Aufgrund von PEP 393 sind der Typ `Py_UNICODE` und alle Funktionen, die diesen Typ verwenden, veraltet (werden aber noch mindestens fünf Jahre lang verfügbar sein). Wenn Sie Low-Level-Unicode-APIs zum Erstellen und Zugreifen auf Unicode-Objekte verwendet haben und die Speicherplatzreduzierung durch PEP 393 nutzen möchten, müssen Sie Ihren Code auf die neue Unicode-API umstellen.

    Wenn Sie jedoch nur High-Level-Funktionen wie `PyUnicode_Concat()`, `PyUnicode_Join()` oder `PyUnicode_FromFormat()` verwendet haben, profitiert Ihr Code automatisch von den neuen Unicode-Darstellungen.

  • PyImport_GetMagicNumber() gibt nun bei einem Fehler -1 zurück.

  • Da ein negativer Wert für das Argument *level* für __import__() nicht mehr gültig ist, gilt dies nun auch für PyImport_ImportModuleLevel(). Dies bedeutet auch, dass der Wert von *level*, der von PyImport_ImportModuleEx() verwendet wird, nun 0 statt -1 ist.

Erstellen von C-Erweiterungen

  • Der Bereich möglicher Dateinamen für C-Erweiterungen wurde verkleinert. Sehr selten verwendete Schreibweisen wurden unterdrückt: Unter POSIX werden Dateien mit den Namen `xxxmodule.so`, `xxxmodule.abi3.so` und `xxxmodule.cpython-*.so` nicht mehr als Implementierung des `xxx`-Moduls erkannt. Wenn Sie solche Dateien generiert haben, müssen Sie auf die anderen Schreibweisen umsteigen (d.h. den String `module` aus den Dateinamen entfernen).

    (Implementiert in bpo-14040.)

Änderungen bei Kommandozeilenschaltern

  • Das Kommandozeilenflagge -Q und zugehörige Artefakte wurden entfernt. Die Codeüberprüfung sys.flags.division_warning muss aktualisiert werden.

    (bpo-10998, beigetragen von Éric Araujo.)

  • Wenn python mit -S gestartet wird, wird import site nicht mehr sitespezifische Pfade zu den Modulsuchpfaden hinzufügen. In früheren Versionen tat es dies.

    (bpo-11591, beigetragen von Carl Meyer mit Überarbeitungen von Éric Araujo.)