Motivation

Von Zeit zu Zeit nimmt Python inkompatible Änderungen an den beworbenen Semantiken von Kernsprachkonstrukten vor oder ändert deren versehentliches (implementierungsabhängiges) Verhalten auf irgendeine Weise. Obwohl dies nie willkürlich geschieht und immer mit dem Ziel geschieht, die Sprache langfristig zu verbessern, ist es kurzfristig umstritten und störend.

PEP 5, Richtlinien für die Sprachentwicklung, schlägt Wege vor, um den Schmerz zu lindern, und diese PEP führt einige Mechanismen zur Unterstützung dessen ein.

PEP 227, Statisch verschachtelte Geltungsbereiche, ist die erste Anwendung und wird hier als Beispiel verwendet.

Wenn ein neues, potenziell inkompatibles Sprachmerkmal hinzugefügt wird, können sich einige Module und Bibliotheken dafür entscheiden, es zu nutzen, während andere dies möglicherweise nicht tun. Diese Spezifikation führt eine Syntax ein, mit der ein Modulautor angeben kann, ob ein bestimmtes Sprachmerkmal in dem Modul verwendet wird oder nicht.

In der Diskussion dieser PEP kommentierten die Leser, dass es zwei Arten von „einstellbaren“ Sprachmerkmalen gibt

• die, die dazu bestimmt sind, schließlich die einzige Option zu werden, zu welchem Zeitpunkt die Angabe ihrer Verwendung nicht mehr notwendig ist. Die Merkmale, für die die Syntax von „Back to the __future__“ PEP 236, Back to the __future__ vorgeschlagen wurde, fallen in diese Kategorie. Diese PEP unterstützt die Deklaration solcher Merkmale und unterstützt die Ausphasung der „alten“ Bedeutung von Konstrukten, deren Semantik sich unter dem neuen Merkmal geändert hat. Sie definiert jedoch keine Richtlinie, welche Merkmale schließlich ausphasen müssen.
• die, die dazu bestimmt sind, für immer optional zu bleiben, z. B. wenn sie eine Standardeinstellung im Interpreter ändern. Ein Beispiel für solche Einstellungen könnte die Anforderung sein, für ein bestimmtes Modul immer Zeilennummern-Instruktionen auszugeben; es werden in dieser Spezifikation keine spezifischen Flags dieser Art vorgeschlagen.

Da ein Hauptziel dieser PEP darin besteht, neue Sprachkonstrukte zu unterstützen, ohne alte Bibliotheken sofort zu brechen, wurde besondere Sorgfalt darauf verwendet, alte Bibliotheken durch die Einführung der neuen Syntax nicht zu brechen.

Syntax

Eine directive_statement ist eine Anweisung der Form

directive_statement: 'directive' ``NAME`` [atom] [';'] NEWLINE

Der Name in der Direktive gibt die Art der Direktive an; er definiert, ob das optionale Atom vorhanden sein kann und ob weitere syntaktische oder semantische Einschränkungen für das Atom gelten. Zusätzlich können, abhängig vom Namen der Direktive, bestimmte zusätzliche syntaktische oder semantische Einschränkungen für die Direktive gelten (z. B. die Platzierung der Direktive im Modul kann auf den Anfang des Moduls beschränkt sein).

In der directive_statement ist directive ein neues Schlüsselwort. Gemäß PEP 5 gilt dieses Schlüsselwort zunächst nur, wenn es in einer directive statement verwendet wird, siehe „Abwärtskompatibilität“ unten.

Semantik

Eine Direktive-Anweisung weist den Python-Interpreter an, eine Quelldatei auf andere Weise zu verarbeiten; die genauen Details dieser Verarbeitung hängen vom Namen der Direktive ab. Das optionale Atom wird typischerweise verarbeitet, wenn der Quellcode verarbeitet wird; die Details dieser Verarbeitung hängen von der Direktive ab.

Spezifische Direktiven: transitional

Wenn eine syntaktische oder semantische Änderung zu Python hinzugefügt wird, die inkompatibel ist, schreibt PEP 5 eine übergangsweise Entwicklung der Sprache vor, bei der das neue Merkmal zunächst neben dem alten verfügbar ist. Ein solcher Übergang ist durch die übergangsweise Direktive möglich.

In einer transitional directive ist NAME ‚transitional‘. Das Atom MUSS vorhanden sein und es MUSS ein NAME sein. Die möglichen Werte für diesen Namen werden definiert, wenn die Sprachänderung definiert wird. Ein Beispiel für eine solche Direktive ist

directive transitional nested_scopes

Die transitional directive MUSS vor jeder anderen Anweisung in einem Modul auftreten, mit Ausnahme der Dokumentationszeichenkette (d. h. sie darf nur als zweite Anweisung eines Moduls erscheinen, wenn die erste Anweisung ein STRING+ ist).

Abwärtskompatibilität

Die Einführung von directive als neues Schlüsselwort kann zu Inkompatibilitäten mit vorhandenem Code führen. Gemäß der Richtlinie in PEP 5 ist directive in der anfänglichen Implementierung dieser Spezifikation nur dann ein neues Schlüsselwort, wenn es in einer gültigen directive_statement verwendet wurde (d. h. wenn es als das erste Nicht-String-Token in einem Modul erschien).

Ungelöste Probleme: directive als erster Bezeichner

Die Verwendung von directive in einem Modul als

directive = 1

(d. h. der Name directive erscheint als erstes Element in einem Modul) behandelt es als Schlüsselwort, nicht als Bezeichner. Es wäre möglich, es als NAME mit einem zusätzlichen Look-ahead-Token zu klassifizieren, aber ein solches Look-ahead ist im Python-Tokenizer nicht verfügbar.

Fragen und Antworten

F: Es sieht so aus, als wäre diese PEP geschrieben worden, um die Definition von Zeichensätzen für Quellcode zu ermöglichen. Ist das richtig?

A: Nein. Auch wenn die Direktiven-Einrichtung erweitert werden kann, um Quellcode-Kodierungen zu ermöglichen, wird keine spezifische Direktive vorgeschlagen.

F: Warum wurde diese PEP dann überhaupt geschrieben?

A: Sie fungiert als Gegenentwurf zu PEP 236, die vorschlägt, die import-Anweisung mit einer neuen Bedeutung zu überladen. Diese PEP ermöglicht es, das Problem auf eine allgemeinere Weise zu lösen.

F: Aber ist es nicht so, als würde man Quellcode-Kodierungen und Sprachänderungen mischen, wie Äpfel und Birnen?

A: Vielleicht. Um den Unterschied zu berücksichtigen, wurde die vordefinierte „transitional“-Direktive definiert.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.