Zusammenfassung

Manche Ideen sind einfach schlecht. Während einige Gedanken zur Python-Entwicklung konstruktiv sind, widersprechen andere so stark den Grundprinzipien von Python, dass es wie die Aufforderung an jemanden wäre, im Kreis zu laufen: Es bringt einen nirgendwo hin, selbst für Python 3000, wo außergewöhnliche Vorschläge erlaubt sind. Dieses PEP versucht, alle BDFL-Äußerungen zu Python 3000 aufzulisten, die sich auf Änderungen beziehen, die nicht stattfinden werden, und auf neue Funktionen, die nicht eingeführt werden, sortiert nach Themen, zusammen mit einer kurzen Erklärung oder einem Verweis auf den relevanten Thread in der python-3000-Mailingliste.

Wenn Sie glauben, eine der aufgeführten Ideen vorschlagen zu müssen, wäre es besser, den Computer zu verlassen, nach draußen zu gehen und sich zu amüsieren. Aktive Betätigung im Freien durch ein Nickerchen auf einer schönen Grasfläche ist produktiver, als eine Idee wieder aufzugreifen, die bereits tot ist, und sich von Leuten sagen zu lassen, wie tot sie ist. Betrachten Sie sich als gewarnt.

Kernsprache

• Python 3000 wird nicht case-sensitiv sein.
• Python 3000 wird keine komplette Neuentwicklung sein.

  Es wird auch nicht C++ oder eine andere Sprache als C als Implementierungssprache verwenden. Vielmehr wird es eine schrittweise Umwandlung der Codebasis geben. Joel Spolskys ausgezeichneter Aufsatz erklärt, warum: http://www.joelonsoftware.com/articles/fog0000000069.html

• self wird nicht implizit.

  Es ist eine *gute Sache*, self explizit zu machen. Es macht den Code klar, indem die Mehrdeutigkeit beseitigt wird, wie eine Variable aufgelöst wird. Es macht auch den Unterschied zwischen Funktionen und Methoden klein.

  Thread: „Draft proposal: Implicit self in Python 3.0“ https://mail.python.org/pipermail/python-dev/2006-January/059468.html

• lambda wird nicht umbenannt.

  Zu einem bestimmten Zeitpunkt war geplant, lambda in Python 3000 zu entfernen. Leider konnte niemand einen besseren Weg finden, anonyme Funktionen bereitzustellen. Und so bleibt lambda bestehen.

  Aber es bleibt so, wie es ist. Die Unterstützung von Anweisungen ist nicht machbar. Es würde die Zulassung von mehrzeiligen lambda-Ausdrücken erfordern, was bedeuten würde, dass ein mehrzeiliger Ausdruck plötzlich existieren könnte. Das würde zum Beispiel mehrzeilige Argumente für Funktionsaufrufe ermöglichen. Das ist einfach nur hässlich.

  Thread: „genexp syntax / lambda“, https://mail.python.org/pipermail/python-3000/2006-April/001042.html

• Python wird keine programmierbare Syntax haben.

  Thread: „It’s a statement! It’s a function! It’s BOTH!“, https://mail.python.org/pipermail/python-3000/2006-April/000286.html

• Es wird keine Syntax für die parallele Iteration im zip()-Stil geben.

  Thread: „Parallel iteration syntax“, https://mail.python.org/pipermail/python-3000/2006-March/000210.html

• Strings werden iterierbar bleiben.

  Thread: „Making strings non-iterable“, https://mail.python.org/pipermail/python-3000/2006-April/000759.html

• Es wird keine Syntax geben, um das Ergebnis eines Generatorausdrucks oder einer Listenkomprehension zu sortieren. sorted() deckt alle Anwendungsfälle ab.

  Thread: „Adding sorting to generator comprehension“, https://mail.python.org/pipermail/python-3000/2006-April/001295.html

• Slices und erweiterte Slices werden nicht verschwinden (auch wenn die APIs __getslice__ und __setslice__ ersetzt werden mögen) und sie werden auch keine Views für die Standardobjekttypen zurückgeben.

  Thread: Future of slices https://mail.python.org/pipermail/python-3000/2006-May/001563.html

• Es wird nicht verboten, eine Schleifenvariable innerhalb des Schleifenkörpers wiederzuverwenden.

  Thread: elimination of scope bleeding of iteration variables https://mail.python.org/pipermail/python-dev/2006-May/064761.html

• Der Parser wird nicht komplexer als LL(1) sein.

  Einfach ist besser als komplex. Diese Idee erstreckt sich auf den Parser. Die Beschränkung der Python-Grammatik auf einen LL(1)-Parser ist ein Segen und kein Fluch. Sie hält uns in Fesseln, die uns davon abhalten, über Bord zu gehen und mit seltsamen Grammatikregeln wie bei einigen anderen dynamischen Sprachen zu enden, die nicht genannt werden sollen, wie z. B. Perl.

• Keine geschweiften Klammern.

  Das ist so offensichtlich, dass kein Verweis auf eine Mailingliste benötigt wird. Führen Sie from __future__ import braces aus, um eine definitive Antwort auf dieses Thema zu erhalten.

• Keine Backticks mehr.

  Backticks (`) werden nicht mehr als Kurzform für repr verwendet – aber das bedeutet nicht, dass sie für andere Zwecke verfügbar sind. Selbst wenn man die Verwirrung bezüglich der Abwärtskompatibilität ignoriert, verursacht das Zeichen selbst zu viele Probleme (in manchen Schriftarten, auf manchen Tastaturen, beim Setzen eines Buches usw.).

  Thread: „new operators via backquoting“, https://mail.python.org/pipermail/python-ideas/2007-January/000054.html

• Die Referenzierung des globalen Namens foo wird nicht als globals.foo geschrieben. Die global-Anweisung bleibt bestehen.

  Threads: „replace globals() and global statement with global builtin object“, https://mail.python.org/pipermail/python-3000/2006-July/002485.html, „Explicit Lexical Scoping (pre-PEP?)“, https://mail.python.org/pipermail/python-dev/2006-July/067111.html

• Es wird keine alternativen Bindungsoperatoren wie := geben.

  Thread: „Explicit Lexical Scoping (pre-PEP?)“, https://mail.python.org/pipermail/python-dev/2006-July/066995.html

• Wir werden keine Container-Literale entfernen. Das heißt, {expr: expr, …}, [expr, …] und (expr, …) bleiben bestehen.

  Thread: „No Container Literals“, https://mail.python.org/pipermail/python-3000/2006-July/002550.html

• Die else-Klausel in while- und for-Schleifen wird ihre Semantik nicht ändern oder entfernt werden.

  Thread: „for/except/else syntax“ https://mail.python.org/pipermail/python-ideas/2009-October/006083.html

Builtins

• zip() wird keine Schlüsselwortargumente oder andere Mechanismen erhalten, um zu verhindern, dass es am Ende der kürzesten Sequenz stoppt.

  Thread: „have zip() raise exception for sequences of different lengths“, https://mail.python.org/pipermail/python-3000/2006-August/003338.html

• hash() wird kein Attribut werden, da Attribute billig zu berechnen sein sollten, was für einen Hash nicht unbedingt der Fall ist.

  Thread: „hash as attribute/property“, https://mail.python.org/pipermail/python-3000/2006-April/000362.html

Standardtypen

• Die Iteration über ein Wörterbuch wird weiterhin die Schlüssel liefern.

  Thread: „Iterating over a dict“, https://mail.python.org/pipermail/python-3000/2006-April/000283.html

  Thread: have iter(mapping) generate (key, value) pairs https://mail.python.org/pipermail/python-3000/2006-June/002368.html

• Es wird keinen frozenlist-Typ geben.

  Thread: „Immutable lists“, https://mail.python.org/pipermail/python-3000/2006-May/002219.html

• int wird keine Subskripte unterstützen, die einen Bereich liefern.

  Thread: „xrange vs. int.__getslice__“, https://mail.python.org/pipermail/python-3000/2006-June/002450.html

Programmierstil

• Die (empfohlene) maximale Zeilenbreite bleibt 80 Zeichen, sowohl für C- als auch für Python-Code.

  Thread: „C style guide“, https://mail.python.org/pipermail/python-3000/2006-March/000131.html

Interaktiver Interpreter

• Der Interpreter-Prompt (>>>) wird sich nicht ändern. Er gibt Guido warme, wohlige Gefühle.

  Thread: „Low-hanging fruit: change interpreter prompt?“, https://mail.python.org/pipermail/python-3000/2006-November/004891.html

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.