Seite 1 von 3

Verfasst: Mittwoch 31. Januar 2007, 17:29
von sape
Leonidas hat geschrieben:
BlackJack hat geschrieben:Das ``print`` wird in die Datei `f` umgeleitet.
Kann übrigens auch jedes andere file-like-object sein, wie StringIO oder sys.stdout.
Und alle anderen die ``>>`` überladen haben.

Code: Alles auswählen

[...]
self.txt_ctrl = wx.TextCtrl(self.panel, style=wx.TE_MULTILINE)
[...]
print >> self.txt_ctrl, "foobar"
[...]
anstatt, das man das so schreibt.

Code: Alles auswählen

self.txt_ctrl.AppendText("foobar")
Ich finde es praktisch. Ist gegen die Benutzung was auszusetzen und sollte ich mir das wider schnell abgewöhnen :? Hmm, ich finde nicht das es die Syntax verkompliziert. :?

lg

Verfasst: Mittwoch 31. Januar 2007, 18:00
von BlackJack
sape hat geschrieben:
Leonidas hat geschrieben:
BlackJack hat geschrieben:Das ``print`` wird in die Datei `f` umgeleitet.
Kann übrigens auch jedes andere file-like-object sein, wie StringIO oder sys.stdout.
Und alle anderen die ``>>`` überladen haben.
Nein! Das hat mit dem binären ``>>``-Operator überhaupt nichts zu tun, das ist ein Sonderfall…
Hmm, ich finde nicht das es die Syntax verkompliziert.
…und weil es ein Sonderfall ist, macht es die Syntax komplizierter. Ein Spezialfall, den man sich merken muss.

Verfasst: Mittwoch 31. Januar 2007, 19:37
von sape
Danke für die Info. Werde es dann auch nicht mehr benutzen.

lg

Verfasst: Mittwoch 31. Januar 2007, 19:51
von birkenfeld
sape hat geschrieben:Danke für die Info. Werde es dann auch nicht mehr benutzen.
Wieso nicht?

Verfasst: Mittwoch 31. Januar 2007, 20:16
von sape
birkenfeld hat geschrieben: Wieso nicht?
Ich versuche die Sachen die als schlecht in Python angesehen werden, zu vermeiden. Erstmal weil ich schönen Code schreiben will den auch andere schön und brauchbar finden. Zweitens kann es ja mal sein das ich mich einem Projekt anschließe und dann sollte man sich ja schon größtenteils an PEP8 halten und Sachen vermeiden die nicht als gut angesehen werden.

Außerdem wenn es ehe in Py3K wegkommt, benutze ich das dann lieber ehe nicht, da ich in diesen Fall darauf auch verzichten kann und beim umstieg weniger umschreiben muss. -- Aber eine Begründung wollte ich dennoch vorher gerne gehabt habe, die ich nun habe.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen (wenn man es nicht für den eigentlichen Einsatzzweck den bitshifting nutzt)?

lg

Verfasst: Mittwoch 31. Januar 2007, 20:22
von birkenfeld
sape hat geschrieben:
birkenfeld hat geschrieben: Wieso nicht?
Ich versuche die Sachen die als schlecht in Python angesehen werden, zu vermeiden. Erstmal weil ich schönen Code schreiben will den auch andere schön und brauchbar finden. Zweitens kann es ja mal sein das ich mich einem Projekt anschließe und dann sollte man sich ja schon größtenteils an PEP8 halten und Sachen vermeiden die nicht als gut angesehen werden.
Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.
Außerdem wenn es ehe in Py3K wegkommt, benutze ich das dann lieber ehe nicht, da ich in diesen Fall darauf auch verzichten kann und beim umstieg weniger umschreiben muss. -- Aber eine Begründung wollte ich dennoch vorher gerne gehaben, die ich nun habe.
Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.
Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen (wenn man es nicht für den eigentlichen Einsatzzweck den bitshifting nutzt)?
Was hat der Bitshifting-Operator mit der speziellen Syntax von print zur Ausgabe an beliebige Streams zu tun?

Verfasst: Mittwoch 31. Januar 2007, 20:33
von sape
birkenfeld hat geschrieben: Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.
Naja das was BlackJack ja schon gesagt hat. Finde ich irgendwie logisch die Begründung von ihm.
birkenfeld hat geschrieben: Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.
Welches Konvertierungstool?
birkenfeld hat geschrieben: Was hat der Bitshifting-Operator mit der speziellen Syntax von print zur Ausgabe an beliebige Streams zu tun?
Nichts hat das damit zu tun und habe ich ja auch nicht gesagt. Aber es sieht gleich aus und kann dann zur Verwirrung führen, weil es zwei Sonderfälle für ein Operator gibt der in zwei fällen unterschiedliche Bedeutung hat. Naja, mich persönlich stört es in dem Fall von >> ehe nicht, da ich kaum Code sehe wo das verwendet wird.

Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen? Das würde mich ja dann doch interessieren.

lg

Verfasst: Mittwoch 31. Januar 2007, 20:39
von birkenfeld
sape hat geschrieben:
birkenfeld hat geschrieben: Wieso sollte `print >>file, x` schlecht sein? Es hat halt nix mit dem Operator `>>` zu tun.
Naja das was BlackJack ja schon gesagt hat. Finde ich irgendwie logisch die Begründung von ihm.
Also dass es ein Speziallfall ist, den man sich merken muss?
Ehrlich gesagt, man kann gar nicht darauf kommen, dass >> in "print >>a" ein Bitshifting-Operator ist, denn letzterer ist ein binärer Operator, während das hier höchstens ein unärer sein kann. (Ist er aber nicht, es ist *kein* Operator, sondern ein Syntaxelement. Und als solches auch nicht schwerer zu merken als z.B. die Bedeutung von ":" in Slices.)
birkenfeld hat geschrieben: Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.
Welches Konvertierungstool?
Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.
Aber hast du eine Begründung die dafür sprechen würde dass weiterhin zu nutzen? Das würde mich ja dann doch interessieren.
`print >>a, b, c, d` sieht schöner aus als `a.write("%s %s %s\n" % (b, c, d))`.

Und gerade wenn man einem Programm, was ursprünglich nur print verwendet, die Ausgabe in beliebige Streams beibringen will, sehr viel schöner umzuschreiben.

Verfasst: Mittwoch 31. Januar 2007, 20:46
von sape
Interessant. Erstens habe ich den ersten Abschnitt von dir nicht gewusst und das Beispiel von dir ist überzeugend. Danke dir für die Klarstellung. :)

Dan hätte ich aber noch einer Frage: Warum wird das dann abgeschaft? (Die alte Begründung kann ja dann nicht zutreffen.). Wird stattdessen ein anderes Zeichen gewählt das die gleiche Aufgabe übernimmt?

lg

Verfasst: Mittwoch 31. Januar 2007, 20:47
von Leonidas
birkenfeld hat geschrieben:
sape hat geschrieben:
birkenfeld hat geschrieben: Gerade das ist eines der Gebiete, wo das automatische Konvertierungstool mit 100% Erfolg eingesetzt werden kann.
Welches Konvertierungstool?
Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.
Wie siehts damit eigentlich aus? Was mich aber etwas an der ganzen Geschichte wundert, dass zum Beispiel die Twisted-Leute scheinbar vorhaben bei Python 2.x zu bleiben, zumindest vorerst.

Verfasst: Mittwoch 31. Januar 2007, 21:01
von sape
Würde ich auch gerne Wissen.

Verfasst: Mittwoch 31. Januar 2007, 21:10
von birkenfeld
sape hat geschrieben: Dan hätte ich aber noch einer Frage: Warum wird das dann abgeschaft? (Die alte Begründung kann ja dann nicht zutreffen.). Wird stattdessen ein anderes Zeichen gewählt das die gleiche Aufgabe übernimmt?
Da print eine Funktion wird, wird es ein Keyword-Argument geben.

Bzw. das Futur ist unzutreffend ;)

Code: Alles auswählen

Python 3.0x (p3yk:53421, Jan 31 2007, 08:41:24)
[GCC 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> Print("a", "b", file=sys.stderr)
a b
Wobei momentan "print" als Statement noch vorhanden ist und die Funktion deswegen großgeschrieben ist.

Verfasst: Mittwoch 31. Januar 2007, 21:14
von birkenfeld
Leonidas hat geschrieben:
birkenfeld hat geschrieben:
sape hat geschrieben:Welches Konvertierungstool?
Das, das Python 2.x-Code in Python 3.0-Code konvertieren wird, wo das problemlos möglich ist.
Wie siehts damit eigentlich aus?
Naja, es existiert und kann schon einige Änderungen, z.B. print oder die neue except-Syntax.
Wo es natürlich schwierig wird, das sind Sachen wie dict.iterkeys()/keys(), weil man da nicht eindeutig sagen kann, ob z.B. "x.keys()" geändert werden muss.
Was mich aber etwas an der ganzen Geschichte wundert, dass zum Beispiel die Twisted-Leute scheinbar vorhaben bei Python 2.x zu bleiben, zumindest vorerst.
Nachdem die Konvertierung nie 100% Zuverlässigkeit erreichen kann, haben die etwas Angst vor der Riesenarbeit, den ganzen Code vollständig zu portieren. Kein Wunder bei der Codebasis...

ein Grund mehr für gescheite Unit Tests (was nicht heißt, dass Twisted keine hat).

Verfasst: Mittwoch 31. Januar 2007, 21:15
von Leonidas
Ist es wirklich eine schlaue Idee, das Keyword-Argument wie ein Builtin zu benennen? Funktional ist es ja eigentlich egal, aber so etwas bin ich normalerweise nicht von Python gewöhnt. Oder wird ``file()`` nun abgeschafft?

Verfasst: Mittwoch 31. Januar 2007, 21:19
von birkenfeld
Leonidas hat geschrieben:Ist es wirklich eine schlaue Idee, das Keyword-Argument wie ein Builtin zu benennen? Funktional ist es ja eigentlich egal, aber so etwas bin ich normalerweise nicht von Python gewöhnt. Oder wird ``file()`` nun abgeschafft?
Nein, das nicht. Aber warum sollte das Keyword nicht so heißen?

Verfasst: Mittwoch 31. Januar 2007, 21:26
von Leonidas
birkenfeld hat geschrieben:Nein, das nicht. Aber warum sollte das Keyword nicht so heißen?
Die gängige "Lehrmeinung" ist ja, dass man keine Namen nehmen sollte, die Builtins überdecken. In dieser Form, würde aber in der Funktion Print der Name file überdeckt. Ok - da diese Funktion höchstwarscheinlich in C implementiert ist, ist es an dieser Stelle von der Funktionalität egal, aber sollte man nicht besser ein gutes Beispiel geben?

Nicht dass dann jemand sowas in seinem Code auch macht und meint: "die Builtins machen es doch auch so!" Andererseits würde der Name ``target`` warscheinlich besser passen, ist auch nicht wesentlich länger zu tippen und ebenso leicht zu merken. Noch dazu ist er etwas neutraler, d.h. er suggeriert nicht, dass da zwingend ein file-Objekt (im Sinne von Instanz von file) hingeschickt werden muss.

Verfasst: Mittwoch 31. Januar 2007, 21:26
von sape
@Birkenfeld:
Naja, man soll doch keine Namen vom builtins verwenden. Oder ist das bei Keywords zulässig? Ich glaube mich zu erinnern das im PEP8 drinstande das man dann lieber ein _ am ende setzen soll im Zweifelsfall wenn kein besserer Name einfällt (Ich glaube das galt auch für Keywords).

Verfasst: Mittwoch 31. Januar 2007, 21:29
von birkenfeld
sape hat geschrieben:@Birkenfeld:
Naja, man soll doch keine Namen vom builtins verwenden. Oder ist das bei Keywords zulässig? Ich glaube mich zu erinnern das im PEP8 drinstande das man dann lieber ein _ am ende setzen soll im Zweifelsfall wenn kein besserer Name einfällt (Ich glaube das galt auch für Keywords).
Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.

Zweitens, bei Keywords *musst* du den Namen verändern, weil die nicht als kwargs zulässig sind.

Verfasst: Mittwoch 31. Januar 2007, 21:36
von Leonidas
birkenfeld hat geschrieben:Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.
Ja, das habe ich ach schon geschrieben. Aber wie sieht das mit der Konsistenz aus. Warum wird nun mit zweierlei Maß gemessen, dass die Builtins etwas dürfen was der normale Programmierer in seinem Code unterlassen sollte.

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, aber das gilt ja nur für CPython, für IronPython oder PyPy muss das gar nicht mehr gelten. Sonst verhalten sich die in C geschriebenen Funktionen ja eigentlich genauso wie in Python geschriebene Funktionen, d.h. es gibt im "Look and Feel" keinen Unterschied.

Verfasst: Mittwoch 31. Januar 2007, 21:40
von birkenfeld
Leonidas hat geschrieben:
birkenfeld hat geschrieben:Erstens gilt das für Funktionen, die du selbst schreibst, weil *in diesen Funktionen* der Name dann anders als sonst gebunden ist. In diesem Fall egal.
Ja, das habe ich ach schon geschrieben. Aber wie sieht das mit der Konsistenz aus. Warum wird nun mit zweierlei Maß gemessen, dass die Builtins etwas dürfen was der normale Programmierer in seinem Code unterlassen sollte.

Und wie soll man den Leuten so etwas klar machen, wenn die mir sagen, dass die die Builtins das gleiche machen. Klar, ich kann sagen, dass die in C implementiert sind, aber das gilt ja nur für CPython, für IronPython oder PyPy muss das gar nicht mehr gelten. Sonst verhalten sich die in C geschriebenen Funktionen ja eigentlich genauso wie in Python geschriebene Funktionen, d.h. es gibt im "Look and Feel" keinen Unterschied.
"A foolish consistency..."

Die Richtlinie ist nicht dazu da, stur einfach so eingehalten zu werden, sondern dazu um dem Programmierer das Leben leicht zu machen.

Wenn du die Funktion nicht schreibst, braucht es dich nicht zu kümmern, ob der Programmierer derselben sich (evtl.) das Leben schwer gemacht hat -- sofern du dir sicher bist dass er alles richtig gemacht hat.