Was ist neu in Python 3.0

Autor:

Guido van Rossum

Dieser Artikel erklärt die neuen Funktionen in Python 3.0 im Vergleich zu 2.6. Python 3.0, auch bekannt als „Python 3000“ oder „Py3K“, ist die erste absichtlich rückwärts inkompatible Python-Version überhaupt. Python 3.0 wurde am 3. Dezember 2008 veröffentlicht. Es gibt mehr Änderungen als in einer typischen Version, und mehr, die für alle Python-Benutzer wichtig sind. Nichtsdestotrotz werden Sie feststellen, dass sich Python nach Verdauung der Änderungen eigentlich nicht so stark verändert hat – wir beheben größtenteils bekannte Ärgernisse und Schönheitsfehler und entfernen viel alten Ballast.

Dieser Artikel versucht nicht, eine vollständige Spezifikation aller neuen Funktionen zu liefern, sondern gibt stattdessen einen praktischen Überblick. Für vollständige Details sollten Sie die Dokumentation für Python 3.0 und/oder die vielen im Text referenzierten PEPs konsultieren. Wenn Sie die vollständige Implementierung und Design-Begründung für eine bestimmte Funktion verstehen möchten, enthalten PEPs normalerweise mehr Details als die reguläre Dokumentation; beachten Sie jedoch, dass PEPs normalerweise nicht auf dem neuesten Stand gehalten werden, sobald eine Funktion vollständig implementiert ist.

Aufgrund von Zeitmangel ist dieses Dokument nicht so vollständig, wie es sein sollte. Wie immer bei einer neuen Version enthält die Datei Misc/NEWS in der Quellcode-Distribution eine Fülle von detaillierten Informationen zu jeder noch so kleinen Änderung.

Häufige Stolpersteine

Dieser Abschnitt listet die wenigen Änderungen auf, die Sie am wahrscheinlichsten stolpern lassen, wenn Sie an Python 2.5 gewöhnt sind.

Views und Iteratoren statt Listen

Einige bekannte APIs geben keine Listen mehr zurück

  • dict-Methoden dict.keys(), dict.items() und dict.values() geben „Views“ statt Listen zurück. Zum Beispiel funktioniert Folgendes nicht mehr: k = d.keys(); k.sort(). Verwenden Sie stattdessen k = sorted(d) (dies funktioniert auch in Python 2.5 und ist genauso effizient).

  • Außerdem werden die Methoden dict.iterkeys(), dict.iteritems() und dict.itervalues() nicht mehr unterstützt.

  • map() und filter() geben Iteratoren zurück. Wenn Sie wirklich eine Liste benötigen und die Eingabesequenzen alle gleich lang sind, ist eine schnelle Lösung, map() in list() einzubinden, z. B. list(map(...)), aber eine bessere Lösung ist oft die Verwendung einer Listen-Komprehension (insbesondere wenn der Originalcode lambda verwendet) oder das Umschreiben des Codes, sodass er keine Liste benötigt. Besonders knifflig ist map(), das für die Seiteneffekte der Funktion aufgerufen wird; die richtige Transformation ist die Verwendung einer regulären for-Schleife (da das Erstellen einer Liste nur Verschwendung wäre).

    Wenn die Eingabesequenzen nicht gleich lang sind, stoppt map() beim Ende der kürzesten Sequenz. Für vollständige Kompatibilität mit map() aus Python 2.x binden Sie die Sequenzen auch in itertools.zip_longest() ein, z. B. map(func, *sequences) wird zu list(map(func, itertools.zip_longest(*sequences))).

  • range() verhält sich jetzt so, wie sich xrange() früher verhalten hat, außer dass es mit Werten beliebiger Größe arbeitet. Letzteres existiert nicht mehr.

  • zip() gibt jetzt einen Iterator zurück.

Ordnungsvergleiche

Python 3.0 hat die Regeln für Ordnungsvergleiche vereinfacht

  • Die Ordnungsvergleichsoperatoren (<, <=, >=, >) lösen eine TypeError-Ausnahme aus, wenn die Operanden keine sinnvolle natürliche Ordnung haben. Daher sind Ausdrücke wie 1 < '', 0 > None oder len <= len nicht mehr gültig, und z. B. None < None löst eine TypeError aus, anstatt False zurückzugeben. Eine Folge davon ist, dass das Sortieren einer heterogenen Liste keinen Sinn mehr ergibt – alle Elemente müssen miteinander vergleichbar sein. Beachten Sie, dass dies nicht für die Operatoren == und != gilt: Objekte unterschiedlicher inkompatibler Typen sind immer ungleich.

  • sorted() und list.sort() akzeptieren das Argument cmp, das eine Vergleichsfunktion bereitstellt, nicht mehr. Verwenden Sie stattdessen das Argument key. Beachten Sie, dass die Argumente key und reverse jetzt „keyword-only“ sind.

  • Die Funktion cmp() sollte als nicht mehr existent behandelt werden, und die spezielle Methode __cmp__() wird nicht mehr unterstützt. Verwenden Sie stattdessen __lt__() zum Sortieren, __eq__() mit __hash__() und bei Bedarf andere Rich-Comparisons. (Wenn Sie die Funktionalität von cmp() wirklich benötigen, könnten Sie den Ausdruck (a > b) - (a < b) als Äquivalent für cmp(a, b) verwenden.)

Ganzzahlen

  • PEP 237: Im Wesentlichen wurde long in int umbenannt. Das heißt, es gibt nur einen integrierten integralen Typ, der int heißt; aber er verhält sich meistens wie der alte long-Typ.

  • PEP 238: Ein Ausdruck wie 1/2 gibt einen Float zurück. Verwenden Sie 1//2, um das Abschneiden zu erhalten. (Die letztere Syntax existiert seit Jahren, mindestens seit Python 2.2.)

  • Die Konstante sys.maxint wurde entfernt, da es keine Begrenzung mehr für den Wert von Ganzzahlen gibt. Allerdings kann sys.maxsize als eine Ganzzahl verwendet werden, die größer ist als jeder praktische Listen- oder String-Index. Sie entspricht der „natürlichen“ Ganzzahlgröße der Implementierung und ist typischerweise dieselbe wie sys.maxint in früheren Versionen auf derselben Plattform (unter der Annahme gleicher Build-Optionen).

  • Die repr() einer langen Ganzzahl enthält nicht mehr das nachgestellte L, sodass Code, der dieses Zeichen bedingungslos entfernt, stattdessen die letzte Ziffer abschneidet. (Verwenden Sie stattdessen str().)

  • Oktale Literale haben nicht mehr das Format 0720; verwenden Sie stattdessen 0o720.

Text vs. Daten statt Unicode vs. 8-Bit

Alles, was Sie über Binärdaten und Unicode wussten, hat sich geändert.

  • Python 3.0 verwendet die Konzepte von Text und (binären) Daten anstelle von Unicode-Strings und 8-Bit-Strings. Jeder Text ist Unicode; kodiertes Unicode wird jedoch als Binärdaten dargestellt. Der Typ für Text ist str, der Typ für Daten ist bytes. Der größte Unterschied zur Situation in 2.x ist, dass jeder Versuch, Text und Daten in Python 3.0 zu mischen, eine TypeError auslöst, während in Python 2.x das Mischen von Unicode und 8-Bit-Strings funktionierte, wenn der 8-Bit-String nur 7-Bit-ASCII-Bytes enthielt, aber eine UnicodeDecodeError ausgelöst wurde, wenn er Nicht-ASCII-Werte enthielt. Dieses wertspezifische Verhalten hat im Laufe der Jahre zu zahlreichen traurigen Gesichtern geführt.

  • Als Konsequenz dieser geänderten Philosophie muss praktisch jeder Code, der Unicode, Kodierungen oder Binärdaten verwendet, wahrscheinlich geändert werden. Die Änderung ist zum Besseren, da in der 2.x-Welt zahlreiche Fehler im Zusammenhang mit dem Mischen von kodiertem und unkodiertem Text auftraten. Um in Python 2.x vorbereitet zu sein, beginnen Sie damit, unicode für allen unkodierten Text und str nur für binäre oder kodierte Daten zu verwenden. Dann erledigt das 2to3-Tool die meiste Arbeit für Sie.

  • Sie können keine u"..."-Literale mehr für Unicode-Text verwenden. Sie müssen jedoch b"..."-Literale für Binärdaten verwenden.

  • Da die Typen str und bytes nicht gemischt werden können, müssen Sie immer explizit zwischen ihnen konvertieren. Verwenden Sie str.encode(), um von str zu bytes zu gelangen, und bytes.decode(), um von bytes zu str zu gelangen. Sie können auch bytes(s, encoding=...) und str(b, encoding=...) verwenden.

  • Wie str ist auch der Typ bytes unveränderlich. Es gibt einen separaten veränderlichen Typ für gepufferte Binärdaten, bytearray. Fast alle APIs, die bytes akzeptieren, akzeptieren auch bytearray. Die veränderliche API basiert auf collections.MutableSequence.

  • Alle Backslashes in Raw-String-Literalen werden wörtlich interpretiert. Das bedeutet, dass '\U'- und '\u'-Escapes in Raw-Strings nicht speziell behandelt werden. Zum Beispiel ist r'\u20ac' in Python 3.0 ein String aus 6 Zeichen, während in 2.6 ur'\u20ac' das einzelne „Euro“-Zeichen war. (Natürlich betrifft diese Änderung nur Raw-String-Literale; das Euro-Zeichen ist in Python 3.0 '\u20ac'.)

  • Der eingebaute abstrakte Typ basestring wurde entfernt. Verwenden Sie stattdessen str. Die Typen str und bytes haben nicht genügend Gemeinsamkeiten, um eine gemeinsame Basisklasse zu rechtfertigen. Das 2to3-Tool (siehe unten) ersetzt jede basestring durch str.

  • Dateien, die als Textdateien geöffnet werden (immer noch der Standardmodus für open()), verwenden immer eine Kodierung, um zwischen Strings (im Speicher) und Bytes (auf der Festplatte) zu übersetzen. Binärdateien (geöffnet mit einem b im Modusargument) verwenden immer Bytes im Speicher. Das bedeutet, dass, wenn eine Datei mit einem falschen Modus oder einer falschen Kodierung geöffnet wird, die I/O wahrscheinlich laut fehlschlägt, anstatt stillschweigend falsche Daten zu erzeugen. Es bedeutet auch, dass selbst Unix-Benutzer den richtigen Modus (Text oder Binär) beim Öffnen einer Datei angeben müssen. Es gibt eine plattformabhängige Standardkodierung, die auf Unix-Systemen mit der Umgebungsvariable LANG (und manchmal auch mit anderen plattformspezifischen, locale-bezogenen Umgebungsvariablen) eingestellt werden kann. In vielen Fällen, aber nicht allen, ist die Systemstandardkodierung UTF-8; Sie sollten sich niemals auf diese Standardkodierung verlassen. Jede Anwendung, die mehr als reines ASCII liest oder schreibt, sollte wahrscheinlich eine Möglichkeit haben, die Kodierung zu überschreiben. Es ist nicht mehr notwendig, die kodierungsabhängigen Streams im codecs-Modul zu verwenden.

  • Die Anfangswerte von sys.stdin, sys.stdout und sys.stderr sind jetzt reine Unicode-Textdateien (d. h. sie sind Instanzen von io.TextIOBase). Um Binärdaten mit diesen Streams zu lesen und zu schreiben, müssen Sie ihr Attribut io.TextIOBase.buffer verwenden.

  • Dateinamen werden als (Unicode-)Strings an und von APIs übergeben. Dies kann plattformspezifische Probleme mit sich bringen, da auf einigen Plattformen Dateinamen beliebige Byte-Strings sind. (Auf Windows werden Dateinamen nativ als Unicode gespeichert.) Als Workaround akzeptieren die meisten APIs (z. B. open() und viele Funktionen im os-Modul), die Dateinamen akzeptieren, sowohl bytes-Objekte als auch Strings, und einige wenige APIs bieten eine Möglichkeit, einen bytes-Rückgabewert zu erhalten. So gibt os.listdir() eine Liste von bytes-Instanzen zurück, wenn das Argument eine bytes-Instanz ist, und os.getcwdb() gibt das aktuelle Arbeitsverzeichnis als bytes-Instanz zurück. Beachten Sie, dass os.listdir(), wenn es eine Liste von Strings zurückgibt, Dateinamen, die nicht korrekt dekodiert werden können, weglässt, anstatt eine UnicodeError auszulösen.

  • Einige System-APIs wie os.environ und sys.argv können ebenfalls Probleme verursachen, wenn die vom System bereitgestellten Bytes nicht mit der Standardkodierung interpretiert werden können. Das Setzen der LANG-Variable und das erneute Ausführen des Programms ist wahrscheinlich der beste Ansatz.

  • PEP 3138: Die repr() eines Strings maskiert nicht mehr Nicht-ASCII-Zeichen. Sie maskiert jedoch weiterhin Steuerzeichen und Codepunkte mit nicht druckbarem Status gemäß dem Unicode-Standard.

  • PEP 3120: Die Standard-Quellcode-Kodierung ist jetzt UTF-8.

  • PEP 3131: Nicht-ASCII-Buchstaben sind jetzt in Bezeichnern erlaubt. (Die Standardbibliothek bleibt jedoch ASCII-orientiert, mit Ausnahme von Mitwirkendennamen in Kommentaren.)

  • Die Module StringIO und cStringIO sind verschwunden. Importieren Sie stattdessen das io-Modul und verwenden Sie io.StringIO oder io.BytesIO für Text bzw. Daten.

  • Siehe auch das Unicode HOWTO, das für Python 3.0 aktualisiert wurde.

Übersicht über Syntaxänderungen

Dieser Abschnitt gibt einen kurzen Überblick über jede syntaktische Änderung in Python 3.0.

Neue Syntax

  • PEP 3107: Anmerkungen für Funktionsargumente und Rückgabewerte. Dies bietet eine standardisierte Methode zur Annotation von Parametern und Rückgabewerten einer Funktion. Diesen Anmerkungen sind keine Semantiken zugeordnet, außer dass sie zur Laufzeit über das Attribut __annotations__ ausgelesen werden können. Die Absicht ist, Experimente durch Metaklassen, Dekoratoren oder Frameworks zu fördern.

  • PEP 3102: Keyword-only arguments. Benannte Parameter, die nach *args in der Parameterliste stehen, *müssen* mit Schlüsselwortsyntax im Aufruf angegeben werden. Sie können auch ein bloßes * in der Parameterliste verwenden, um anzuzeigen, dass Sie keine variable Liste von Argumenten akzeptieren, aber Keyword-only arguments haben.

  • Schlüsselwortargumente sind nach der Liste der Basisklassen in einer Klassendefinition zulässig. Dies wird durch die neue Konvention zur Angabe einer Metaklasse verwendet (siehe nächster Abschnitt), kann aber auch für andere Zwecke verwendet werden, solange die Metaklasse dies unterstützt.

  • PEP 3104: nonlocal-Anweisung. Mit nonlocal x können Sie jetzt direkt eine Variable in einem äußeren (aber nicht globalen) Gültigkeitsbereich zuweisen. nonlocal ist ein neues reserviertes Wort.

  • PEP 3132: Erweitertes Entpacken von Iterables. Sie können jetzt Dinge schreiben wie a, b, *rest = some_sequence. Und sogar *rest, a = stuff. Das rest-Objekt ist immer eine (möglicherweise leere) Liste; die rechte Seite kann ein beliebiges Iterable sein. Beispiel

    (a, *rest, b) = range(5)

    Dies setzt a auf 0, b auf 4 und rest auf [1, 2, 3].

  • Dictionary Comprehensions: {k: v for k, v in stuff} bedeutet dasselbe wie dict(stuff), ist aber flexibler. (Dies ist PEP 274 bestätigt. :-)

  • Set-Literale, z. B. {1, 2}. Beachten Sie, dass {} ein leeres Dictionary ist; verwenden Sie set() für ein leeres Set. Set Comprehensions werden ebenfalls unterstützt; z. B. bedeutet {x for x in stuff} dasselbe wie set(stuff), ist aber flexibler.

  • Neue Oktal-Literale, z. B. 0o720 (bereits in 2.6). Die alten Oktal-Literale (0720) sind weggefallen.

  • Neue Binär-Literale, z. B. 0b1010 (bereits in 2.6), und es gibt eine neue entsprechende eingebaute Funktion, bin().

  • Byte-Literale werden mit einem führenden b oder B eingeführt, und es gibt eine neue entsprechende eingebaute Funktion, bytes().

Geänderte Syntax

  • PEP 3109 und PEP 3134: neue raise-Anweisungssyntax: raise [expr [from expr]]. Siehe unten.

  • as und with sind jetzt reservierte Wörter. (Tatsächlich bereits seit 2.6.)

  • True, False und None sind reservierte Wörter. (2.6 hat die Einschränkungen für None bereits teilweise durchgesetzt.)

  • Änderung von except exc, var zu except exc as var. Siehe PEP 3110.

  • PEP 3115: Neue Metaklassen-Syntax. Anstatt

    class C:
    __metaclass__ = M
    ...

    müssen Sie jetzt

    class C(metaclass=M):
    ...

    verwenden. Die Modul-globale Variable __metaclass__ wird nicht mehr unterstützt. (Sie war eine Krücke, um die Standardverwendung von Klassen im neuen Stil zu erleichtern, ohne jede Klasse von object abzuleiten.)

  • List Comprehensions unterstützen nicht mehr die syntaktische Form [... for var in item1, item2, ...]. Verwenden Sie stattdessen [... for var in (item1, item2, ...)]. Beachten Sie auch, dass List Comprehensions andere Semantiken haben: Sie sind eher syntaktischer Zucker für einen Generator-Ausdruck innerhalb eines list()-Konstruktors, und insbesondere die Schleifensteuerungsvariablen werden nicht mehr in den umgebenden Gültigkeitsbereich geleckt.

  • Das Auslassungszeichen (...) kann überall als atomarer Ausdruck verwendet werden. (Zuvor war es nur in Slices zulässig.) Außerdem muss es jetzt als ... geschrieben werden. (Zuvor konnte es auch als . . . geschrieben werden, durch einen bloßen Zufall der Grammatik.)

Entfernte Syntax

  • PEP 3113: Tupel-Parameter-Entpacken entfernt. Sie können nicht mehr def foo(a, (b, c)): ... schreiben. Verwenden Sie stattdessen def foo(a, b_c): b, c = b_c.

  • Backticks entfernt (verwenden Sie stattdessen repr()).

  • Entfernt <> (verwenden Sie stattdessen !=).

  • Entferntes Schlüsselwort: exec() ist kein Schlüsselwort mehr; es bleibt als Funktion. (Glücklicherweise wurde die Funktionssyntax auch in 2.x akzeptiert.) Beachten Sie auch, dass exec() keinen Stream-Argument mehr annimmt; anstelle von exec(f) können Sie exec(f.read()) verwenden.

  • Ganzzahl-Literale unterstützen kein nachgestelltes l oder L mehr.

  • Zeichenketten-Literale unterstützen kein führendes u oder U mehr.

  • Die Syntax from module import * ist nur auf Modulebene zulässig, nicht mehr innerhalb von Funktionen.

  • Die einzig akzeptable Syntax für relative Importe ist from .[module] import name. Alle import-Formen, die nicht mit . beginnen, werden als absolute Importe interpretiert. (PEP 328)

  • Klassische Klassen sind weggefallen.

Änderungen, die bereits in Python 2.6 vorhanden sind

Da viele Benutzer wahrscheinlich direkt von Python 2.5 auf Python 3.0 umsteigen, erinnert dieser Abschnitt den Leser an neue Funktionen, die ursprünglich für Python 3.0 entwickelt wurden, aber nach Python 2.6 zurückportiert wurden. Die entsprechenden Abschnitte in Was ist neu in 2.6 sollten für längere Beschreibungen konsultiert werden.

Änderungen in der Bibliothek

Aus Zeitgründen deckt dieses Dokument die sehr umfangreichen Änderungen an der Standardbibliothek nicht erschöpfend ab. PEP 3108 ist die Referenz für die wichtigsten Änderungen an der Bibliothek. Hier ist eine kurze Übersicht

  • Viele alte Module wurden entfernt. Einige, wie gopherlib (nicht mehr verwendet) und md5 (ersetzt durch hashlib), wurden bereits durch PEP 4 als veraltet gekennzeichnet. Andere wurden aufgrund der Entfernung der Unterstützung für verschiedene Plattformen wie Irix, BeOS und Mac OS 9 entfernt (siehe PEP 11). Einige Module wurden auch für die Entfernung in Python 3.0 ausgewählt, da sie wenig genutzt wurden oder ein besserer Ersatz existiert. Siehe PEP 3108 für eine vollständige Liste.

  • Das Paket bsddb3 wurde entfernt, da seine Präsenz in der Kernstandardbibliothek im Laufe der Zeit aufgrund von Testinstabilitäten und dem Veröffentlichungsplan von Berkeley DB eine besondere Belastung für die Kernentwickler darstellte. Das Paket ist jedoch lebendig und gut gepflegt und wird extern unter https://www.jcea.es/programacion/pybsddb.htm gepflegt.

  • Einige Module wurden umbenannt, weil ihr alter Name gegen PEP 8 verstieß oder aus verschiedenen anderen Gründen. Hier ist die Liste

    Alter Name

    Neuer Name

    _winreg

    winreg

    ConfigParser

    configparser

    copy_reg

    copyreg

    Queue

    queue

    SocketServer

    socketserver

    markupbase

    _markupbase

    repr

    reprlib

    test.test_support

    test.support

  • Ein gängiges Muster in Python 2.x ist, eine Version eines Moduls in reinem Python zu haben, mit einer optionalen beschleunigten Version, die als C-Erweiterung implementiert ist; zum Beispiel pickle und cPickle. Dies legt die Last des Imports der beschleunigten Version und des Zurückfallens auf die reine Python-Version auf jeden Benutzer dieser Module. In Python 3.0 werden die beschleunigten Versionen als Implementierungsdetails der reinen Python-Versionen betrachtet. Benutzer sollten immer die Standardversion importieren, die versucht, die beschleunigte Version zu importieren und auf die reine Python-Version zurückzufallen. Das Paar pickle / cPickle hat diese Behandlung erhalten. Das Modul profile steht für 3.1 auf der Liste. Das Modul StringIO wurde in eine Klasse im Modul io umgewandelt.

  • Einige verwandte Module wurden zu Paketen zusammengefasst, und normalerweise wurden die Modulnamen vereinfacht. Die resultierenden neuen Pakete sind

    • dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).

    • html (HTMLParser, htmlentitydefs).

    • http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).

    • tkinter (alle Tkinter-bezogenen Module außer turtle). Die Zielgruppe von turtle kümmert sich nicht wirklich um tkinter. Beachten Sie auch, dass seit Python 2.6 die Funktionalität von turtle stark erweitert wurde.

    • urllib (urllib, urllib2, urlparse, robotparse).

    • xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

Einige weitere Änderungen an Standardbibliotheksmodulen, die nicht von PEP 3108 abgedeckt sind

  • Modul sets entfernt. Verwenden Sie die eingebaute Klasse set().

  • Bereinigung des Moduls sys: entfernt sys.exitfunc(), sys.exc_clear(), sys.exc_type, sys.exc_value, sys.exc_traceback. (Beachten Sie, dass sys.last_type usw. bestehen bleiben.)

  • Bereinigung des Typs array.array: die Methoden read() und write() sind weg; verwenden Sie stattdessen fromfile() und tofile(). Auch der Typcode 'c' für Arrays ist weg – verwenden Sie entweder 'b' für Bytes oder 'u' für Unicode-Zeichen.

  • Bereinigung des Moduls operator: entfernt sequenceIncludes() und isCallable().

  • Bereinigung des Moduls thread: acquire_lock() und release_lock() sind weg; verwenden Sie stattdessen acquire() und release().

  • Bereinigung des random-Moduls: Die API jumpahead() wurde entfernt.

  • Das Modul new ist weggefallen.

  • Die Funktionen os.tmpnam(), os.tempnam() und os.tmpfile() wurden zugunsten des Moduls tempfile entfernt.

  • Das Modul tokenize wurde so geändert, dass es mit Bytes arbeitet. Der Haupteinstiegspunkt ist nun tokenize.tokenize() anstelle von generate_tokens.

  • string.letters und seine Freunde (string.lowercase und string.uppercase) sind weggefallen. Verwenden Sie stattdessen string.ascii_letters usw. (Der Grund für die Entfernung ist, dass string.letters und Freunde ein lokalabhängiges Verhalten hatten, was für solch attraktiv benannte globale „Konstanten“ eine schlechte Idee ist.)

  • Das Modul __builtin__ wurde in builtins umbenannt (Unterstriche entfernt, ein „s“ hinzugefügt). Die Variable __builtins__, die in den meisten globalen Namensräumen gefunden wird, ist unverändert. Um eine eingebaute Funktion zu ändern, sollten Sie builtins und nicht __builtins__ verwenden!

PEP 3101: Ein neuer Ansatz für die Formatierung von Zeichenketten

  • Ein neues System für integrierte Zeichenkettenformatierungsoperationen ersetzt den Zeichenkettenformatierungsoperator %. (Der %-Operator wird jedoch weiterhin unterstützt; er wird in Python 3.1 als veraltet gelten und später aus der Sprache entfernt werden.) Lesen Sie PEP 3101 für alle Details.

Änderungen an Ausnahmen

Die APIs zum Auslösen und Abfangen von Ausnahmen wurden bereinigt und neue leistungsstarke Funktionen hinzugefügt.

  • PEP 352: Alle Ausnahmen müssen von BaseException abgeleitet sein (direkt oder indirekt). Dies ist die Wurzel der Ausnahmenhierarchie. Dies ist keine neue Empfehlung mehr, aber die *Anforderung*, von BaseException zu erben, ist neu. (Python 2.6 erlaubte immer noch die Auslösung von klassischen Klassen und schränkte nicht ein, was aufgefangen werden kann.) Infolgedessen sind Zeichenkettenausnahmen endlich wirklich und vollständig tot.

  • Fast alle Ausnahmen sollten tatsächlich von Exception abgeleitet werden; BaseException sollte nur als Basisklasse für Ausnahmen verwendet werden, die nur auf oberster Ebene behandelt werden sollen, wie z. B. SystemExit oder KeyboardInterrupt. Das empfohlene Idiom zum Behandeln aller Ausnahmen außer der letztgenannten Kategorie ist die Verwendung von except Exception.

  • StandardError wurde entfernt.

  • Ausnahmen verhalten sich nicht mehr wie Sequenzen. Verwenden Sie stattdessen das Attribut args.

  • PEP 3109: Auslösen von Ausnahmen. Sie müssen nun raise Exception(args) anstelle von raise Exception, args verwenden. Außerdem können Sie keinen Traceback mehr explizit angeben; wenn Sie dies tun müssen, können Sie direkt dem Attribut __traceback__ zuweisen (siehe unten).

  • PEP 3110: Abfangen von Ausnahmen. Sie müssen nun except SomeException as variable anstelle von except SomeException, variable verwenden. Darüber hinaus wird die *Variable* explizit gelöscht, wenn der except-Block verlassen wird.

  • PEP 3134: Ausnahmeverkettung. Es gibt zwei Fälle: implizite Verkettung und explizite Verkettung. Implizite Verkettung tritt auf, wenn eine Ausnahme in einem except- oder finally-Handler-Block ausgelöst wird. Dies geschieht normalerweise aufgrund eines Fehlers im Handler-Block; wir nennen dies eine *sekundäre* Ausnahme. In diesem Fall wird die ursprüngliche Ausnahme (die gerade behandelt wurde) als Attribut __context__ der sekundären Ausnahme gespeichert. Explizite Verkettung wird mit dieser Syntax aufgerufen

    raise SecondaryException() from primary_exception

    (wobei primary_exception ein beliebiger Ausdruck ist, der ein Ausnahmeobjekt erzeugt, wahrscheinlich eine zuvor abgefangene Ausnahme). In diesem Fall wird die primäre Ausnahme im Attribut __cause__ der sekundären Ausnahme gespeichert. Der Traceback, der gedruckt wird, wenn eine unbehandelte Ausnahme auftritt, durchläuft die Kette von __cause__- und __context__-Attributen und gibt für jede Komponente der Kette einen separaten Traceback aus, mit der primären Ausnahme oben. (Java-Benutzer erkennen dieses Verhalten möglicherweise.)

  • PEP 3134: Ausnahmeobjekte speichern nun ihren Traceback als Attribut __traceback__. Das bedeutet, dass ein Ausnahmeobjekt nun alle Informationen enthält, die sich auf eine Ausnahme beziehen, und es gibt weniger Gründe, sys.exc_info() zu verwenden (obwohl letzteres nicht entfernt wurde).

  • Einige Fehlermeldungen werden verbessert, wenn Windows ein Erweiterungsmodul nicht laden kann. Zum Beispiel ist error code 193 jetzt %1 ist keine gültige Win32 Anwendung. Zeichenketten gehen nun mit Nicht-englischen Lokalen um.

Sonstige Änderungen

Operatoren und spezielle Methoden

  • != gibt nun das Gegenteil von == zurück, es sei denn, == gibt NotImplemented zurück.

  • Das Konzept der „ungebundenen Methoden“ wurde aus der Sprache entfernt. Wenn auf eine Methode als Klassenattribut verwiesen wird, erhalten Sie nun ein einfaches Funktionsobjekt.

  • __getslice__(), __setslice__() und __delslice__() wurden entfernt. Die Syntax a[i:j] wird nun zu a.__getitem__(slice(i, j)) (oder __setitem__() oder __delitem__(), wenn als Zuweisungs- oder Löschziel verwendet).

  • PEP 3114: Die Standardmethode next() wurde in __next__() umbenannt.

  • Die speziellen Methoden __oct__() und __hex__() wurden entfernt – oct() und hex() verwenden nun __index__(), um das Argument in eine Ganzzahl umzuwandeln.

  • Unterstützung für __members__ und __methods__ entfernt.

  • Die Funktionsattribute mit dem Namen func_X wurden in die Form __X__ umbenannt, wodurch diese Namen im Namensraum für Funktionsattribute für benutzerdefinierte Attribute frei werden. Genauer gesagt, wurden func_closure, func_code, func_defaults, func_dict, func_doc, func_globals, func_name in __closure__, __code__, __defaults__, __dict__, __doc__, __globals__, __name__, umbenannt.

  • __nonzero__() ist nun __bool__().

Builtins

  • PEP 3135: Neues super(). Sie können nun super() ohne Argumente aufrufen und (vorausgesetzt, dies geschieht in einer regulären Instanzmethode, die innerhalb einer class-Anweisung definiert ist) werden die richtige Klasse und Instanz automatisch ausgewählt. Mit Argumenten ist das Verhalten von super() unverändert.

  • PEP 3111: raw_input() wurde in input() umbenannt. Das heißt, die neue Funktion input() liest eine Zeile von sys.stdin und gibt sie mit entferntem Zeilenumbruch zurück. Sie löst EOFError aus, wenn die Eingabe vorzeitig beendet wird. Um das alte Verhalten von input() zu erhalten, verwenden Sie eval(input()).

  • Eine neue integrierte Funktion next() wurde hinzugefügt, um die Methode __next__() für ein Objekt aufzurufen.

  • Die Rundungsstrategie und der Rückgabetyp der Funktion round() haben sich geändert. Exakte Halbwerte werden nun zum nächsten geraden Ergebnis gerundet statt vom Nullpunkt weg. (Zum Beispiel gibt round(2.5) nun 2 statt 3 zurück.) round(x[, n]) delegiert nun an x.__round__([n]), anstatt immer einen Float zurückzugeben. Es gibt im Allgemeinen eine Ganzzahl zurück, wenn es mit einem Argument aufgerufen wird, und einen Wert vom Typ von x, wenn es mit zwei Argumenten aufgerufen wird.

  • intern() wurde nach sys.intern() verschoben.

  • Entfernt: apply(). Anstelle von apply(f, args) verwenden Sie f(*args).

  • Entfernt: callable(). Anstelle von callable(f) können Sie isinstance(f, collections.Callable) verwenden. Die Funktion operator.isCallable() ist ebenfalls weggefallen.

  • Entfernt: coerce(). Diese Funktion dient nun keinem Zweck mehr, da klassische Klassen weggefallen sind.

  • Entfernt: execfile(). Anstelle von execfile(fn) verwenden Sie exec(open(fn).read()).

  • Den Typ file entfernt. Verwenden Sie stattdessen open(). Es gibt nun mehrere verschiedene Arten von Streams, die `open` im Modul io zurückgeben kann.

  • Entfernt: reduce(). Verwenden Sie functools.reduce(), wenn Sie es unbedingt benötigen. In 99 % der Fälle ist jedoch eine explizite for-Schleife lesbarer.

  • Entfernt: reload(). Verwenden Sie imp.reload().

  • Entfernt. dict.has_key() – verwenden Sie stattdessen den Operator in.

Build- und C-API-Änderungen

Aus Zeitgründen ist dies eine *sehr* unvollständige Liste der Änderungen an der C-API.

  • Die Unterstützung für mehrere Plattformen wurde eingestellt, darunter unter anderem Mac OS 9, BeOS, RISCOS, Irix und Tru64.

  • PEP 3118: Neue Buffer-API.

  • PEP 3121: Initialisierung & Finalisierung von Erweiterungsmodulen.

  • PEP 3123: Anpassung von PyObject_HEAD an Standard-C.

  • Keine C-API-Unterstützung mehr für eingeschränkte Ausführung.

  • Die C-API-Funktionen PyNumber_Coerce(), PyNumber_CoerceEx(), PyMember_Get() und PyMember_Set() wurden entfernt.

  • Neue C-API PyImport_ImportModuleNoBlock(), funktioniert wie PyImport_ImportModule(), blockiert aber nicht beim Import-Lock (gibt stattdessen einen Fehler zurück).

  • Der boolesche Konvertierungs-Slot und die Methode auf C-Ebene wurden umbenannt: nb_nonzero ist nun nb_bool.

  • METH_OLDARGS und WITH_CYCLE_GC wurden aus der C-API entfernt.

Leistung

Das Nettoergebnis der 3.0-Generalisierungen ist, dass Python 3.0 den Pystone-Benchmark etwa 10 % langsamer ausführt als Python 2.5. Wahrscheinlich ist die Entfernung der Sonderbehandlung für kleine Ganzzahlen die Hauptursache. Es gibt Raum für Verbesserungen, aber diese werden nach der Veröffentlichung von 3.0 erfolgen!

Portierung auf Python 3.0

Für die Portierung bestehenden Python 2.5- oder 2.6-Quellcodes auf Python 3.0 ist die beste Strategie die folgende:

  1. (Voraussetzung:) Beginnen Sie mit einer ausgezeichneten Testabdeckung.

  2. Portieren Sie auf Python 2.6. Dies sollte nicht mehr Aufwand erfordern als die durchschnittliche Portierung von Python 2.x auf Python 2.(x+1). Stellen Sie sicher, dass alle Ihre Tests erfolgreich sind.

  3. (Immer noch mit 2.6:) Aktivieren Sie den Kommandozeilenschalter -3. Dies aktiviert Warnungen zu Funktionen, die in 3.0 entfernt (oder geändert) werden. Führen Sie Ihre Testsuite erneut aus und beheben Sie Code, für den Sie Warnungen erhalten, bis keine Warnungen mehr angezeigt werden und alle Ihre Tests immer noch erfolgreich sind.

  4. Führen Sie den Quellcode-zu-Quellcode-Übersetzer 2to3 über Ihren Quellcodepfad aus. Führen Sie das Ergebnis der Übersetzung unter Python 3.0 aus. Korrigieren Sie manuell alle verbleibenden Probleme, bis alle Tests wieder erfolgreich sind.

Es wird nicht empfohlen, Quellcode zu schreiben, der unverändert unter Python 2.6 und 3.0 läuft; Sie müssten einen sehr verdrehten Programmierstil verwenden, z. B. print-Anweisungen, Metaklassen und vieles mehr vermeiden. Wenn Sie eine Bibliothek pflegen, die sowohl Python 2.6 als auch 3.0 unterstützen muss, ist der beste Ansatz, Schritt 3 oben zu ändern, indem Sie die 2.6-Version des Quellcodes bearbeiten und den 2to3-Übersetzer erneut ausführen, anstatt die 3.0-Version des Quellcodes zu bearbeiten.

Für die Portierung von C-Erweiterungen auf Python 3.0 siehe Portierung von Erweiterungsmodulen auf Python 3.