__future__ — Definitionen zukünftiger Anweisungen

Quellcode: Lib/__future__.py


Importe der Form from __future__ import feature werden future statements genannt. Diese werden vom Python-Compiler speziell behandelt, um die Verwendung neuer Python-Funktionen in Modulen, die die future statement enthalten, vor der Veröffentlichung, in der die Funktion zum Standard wird, zu ermöglichen.

Obwohl diese future statements vom Python-Compiler eine zusätzliche Sonderbedeutung erhalten, werden sie wie jeder andere Import-Statement ausgeführt und das Modul __future__ existiert und wird vom Import-System genauso behandelt, wie jedes andere Python-Modul auch. Dieses Design dient drei Zwecken:

  • Um bestehende Tools, die Import-Statements analysieren und die von ihnen importierten Module erwarten zu finden, nicht zu verwirren.

  • Um zu dokumentieren, wann inkompatible Änderungen eingeführt wurden und wann sie obligatorisch werden oder geworden sind. Dies ist eine Form ausführbarer Dokumentation und kann programmatisch durch Importieren von __future__ und Untersuchen seines Inhalts inspiziert werden.

  • Um sicherzustellen, dass future statements unter Versionen vor Python 2.1 zumindest Laufzeit-Ausnahmen erzeugen (der Import von __future__ schlägt fehl, da es vor 2.1 kein Modul dieses Namens gab).

Modulinhalt

Keine Feature-Beschreibung wird jemals aus __future__ gelöscht. Seit seiner Einführung in Python 2.1 haben die folgenden Features über diesen Mechanismus Eingang in die Sprache gefunden:

Feature

Optional in

Obligatorisch in

Effekt

__future__.nested_scopes

2.1.0b1

2.2

PEP 227: Statically Nested Scopes

__future__.generators

2.2.0a1

2.3

PEP 255: Simple Generators

__future__.division

2.2.0a2

3.0

PEP 238: Changing the Division Operator

__future__.absolute_import

2.5.0a1

3.0

PEP 328: Imports: Multi-Line and Absolute/Relative

__future__.with_statement

2.5.0a1

2.6

PEP 343: The “with” Statement

__future__.print_function

2.6.0a2

3.0

PEP 3105: Make print a function

__future__.unicode_literals

2.6.0a2

3.0

PEP 3112: Bytes literals in Python 3000

__future__.generator_stop

3.5.0b1

3.7

PEP 479: StopIteration handling inside generators

__future__.annotations

3.7.0b1

Niemals [1]

PEP 563: Postponed evaluation of annotations, PEP 649: Deferred evaluation of annotations using descriptors

class __future__._Feature

Jede Anweisung in __future__.py hat die Form

FeatureName = _Feature(OptionalRelease, MandatoryRelease,
                       CompilerFlag)

wobei normalerweise *OptionalRelease* kleiner als *MandatoryRelease* ist und beide 5-Tupel derselben Form wie sys.version_info sind.

(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
 PY_MINOR_VERSION, # the 1; an int
 PY_MICRO_VERSION, # the 0; an int
 PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
 PY_RELEASE_SERIAL # the 3; an int
)
_Feature.getOptionalRelease()

*OptionalRelease* zeichnet die erste Veröffentlichung auf, in der das Feature akzeptiert wurde.

_Feature.getMandatoryRelease()

Für ein *MandatoryRelease*, das noch nicht stattgefunden hat, prognostiziert *MandatoryRelease* die Veröffentlichung, in der das Feature Teil der Sprache wird.

Andernfalls zeichnet *MandatoryRelease* auf, wann das Feature Teil der Sprache wurde; in Veröffentlichungen ab diesem Zeitpunkt müssen Module keine future statement mehr verwenden, um das betreffende Feature zu nutzen, dürfen aber solche Imports weiterhin verwenden.

*MandatoryRelease* kann auch None sein, was bedeutet, dass ein geplantes Feature verworfen wurde oder noch nicht entschieden ist.

_Feature.compiler_flag

*CompilerFlag* ist das (Bitfeld-)Flag, das im vierten Argument der eingebauten Funktion compile() übergeben werden sollte, um das Feature in dynamisch kompiliertem Code zu aktivieren. Dieses Flag wird im Attribut _Feature.compiler_flag von _Feature-Instanzen gespeichert.

Siehe auch

Future Statements

Wie der Compiler mit Future-Imports umgeht.

PEP 236 - Back to the __future__

Der ursprüngliche Vorschlag für den __future__-Mechanismus.