Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 3105 – print als Funktion

Autor:
Georg Brandl <georg at python.org>
Status:
Final
Typ:
Standards Track
Erstellt:
19. Nov. 2006
Python-Version:
3.0
Post-History:


Inhaltsverzeichnis

Zusammenfassung

Der Titel sagt alles – diese PEP schlägt eine neue integrierte Funktion namens print() vor, die die print-Anweisung ersetzt und eine spezifische Signatur für die neue Funktion vorschlägt.

Begründung

Die print-Anweisung steht schon lange auf Listen fragwürdiger Sprachmerkmale, die in Python 3000 entfernt werden sollen, wie z. B. in Guidos Präsentation „Python Regrets“ [1]. Daher ist das Ziel dieser PEP nicht neu, auch wenn sie unter Python-Entwicklern viel Diskussionsstoff hervorrufen mag.

Die folgenden Argumente für eine print()-Funktion sind aus einer python-3000-Nachricht von Guido selbst destilliert [2]

  • print ist die einzige Funktionalität auf Anwendungsebene, der eine eigene Anweisung gewidmet ist. Innerhalb von Pythons Welt wird Syntax im Allgemeinen als letztes Mittel eingesetzt, wenn etwas ohne Hilfe des Compilers nicht möglich ist. Print qualifiziert sich nicht für eine solche Ausnahme.
  • Zu einem bestimmten Zeitpunkt der Anwendungsentwicklung verspürt man oft das Bedürfnis, die print-Ausgabe durch etwas Anspruchsvolleres zu ersetzen, wie z. B. Logging-Aufrufe oder Aufrufe in eine andere I/O-Bibliothek. Mit einer print()-Funktion ist dies ein direkter Zeichenkettenersatz; heute ist es ein Durcheinander, das all diese Klammern hinzufügt und möglicherweise die Syntax im Stil von >>stream konvertiert.
  • Eine spezielle Syntax für print zu haben, stellt eine viel größere Hürde für die Weiterentwicklung dar, z. B. ist eine hypothetische neue printf()-Funktion nicht weit hergeholt, wenn sie neben einer print()-Funktion existiert.
  • Es gibt keine einfache Möglichkeit, print-Anweisungen in einen anderen Aufruf zu konvertieren, wenn ein anderer Trennzeichen benötigt wird, nicht Leerzeichen oder gar keins. Außerdem gibt es überhaupt keine einfache Möglichkeit, Objekte bequem mit einem anderen Trennzeichen als einem Leerzeichen zu drucken.
  • Wenn print() eine Funktion ist, wäre es viel einfacher, sie innerhalb eines Moduls (nur def print(*args):...) oder sogar programmintern (z. B. durch Platzieren einer anderen Funktion in __builtin__.print) zu ersetzen. So wie es ist, kann man dies tun, indem man eine Klasse mit einer write()-Methode schreibt und diese sys.stdout zuweist – das ist nicht schlecht, aber definitiv ein viel größerer konzeptioneller Sprung und funktioniert auf einer anderen Ebene als print.

Spezifikation

Die Signatur für print(), entnommen aus verschiedenen Mailinglisten und kürzlich in der python-3000-Liste gepostet [3], lautet:

def print(*args, sep=' ', end='\n', file=None)

Ein Aufruf wie

print(a, b, c, file=sys.stderr)

wird dem heutigen

print >>sys.stderr, a, b, c

entsprechen, während die optionalen Argumente sep und end angeben, was zwischen bzw. nach den Argumenten gedruckt wird.

Das softspace-Merkmal (ein halb-geheimes Attribut für Dateien, das derzeit verwendet wird, um print mitzuteilen, ob vor dem ersten Element ein Leerzeichen eingefügt werden soll) wird entfernt. Daher wird es keine direkte Übersetzung für das heutige

print "a",
print

geben, das kein Leerzeichen zwischen dem "a" und dem Zeilenumbruch druckt.

Abwärtskompatibilität

Die in dieser PEP vorgeschlagenen Änderungen machen die meisten heutigen print-Anweisungen ungültig. Nur diejenigen, die zufällig Klammern um alle ihre Argumente haben, bleiben in Version 3.0 gültige Python-Syntax. Von diesen werden nur diejenigen, die einen einzelnen Wert in Klammern drucken, weiterhin dasselbe tun. Zum Beispiel, in 2.x

>>> print ("Hello")
Hello
>>> print ("Hello", "world")
('Hello', 'world')

während in 3.0

>>> print ("Hello")
Hello
>>> print ("Hello", "world")
Hello world

Glücklicherweise kann print, da es sich in Python 2 um eine Anweisung handelt, zuverlässig und eindeutig von einem automatisierten Werkzeug erkannt und ersetzt werden, sodass keine größeren Portierungsprobleme auftreten sollten (vorausgesetzt, jemand schreibt das erwähnte Werkzeug).

Implementierung

Die vorgeschlagenen Änderungen wurden im Python 3000-Branch in den Subversion-Revisionen 53685 bis 53704 implementiert. Der Großteil des Legacy-Codes in der Bibliothek wurde ebenfalls konvertiert, aber es ist eine fortlaufende Anstrengung, jede `print`-Anweisung zu finden, die möglicherweise noch in der Distribution verblieben ist.

Referenzen


Quelle: https://github.com/python/peps/blob/main/peps/pep-3105.rst

Zuletzt geändert: 2025-02-01 08:59:27 GMT