Das deutsche Python-Forum

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.

@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).

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.

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.

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.

birkenfeld hat geschrieben:"A foolish consistency..."

Das ist mir schon klar, aber ich finde dass target eine brauchbare Alternative ist. Wie dem auch sei, egal..

Eigentlich sollte dieser Thread auch schon laengst abgesplittet worden sein

Ich glaube es war auch "stream" im Gespräch.

Nur ist auf python-3000 keiner auf die Idee gekommen, an "file" könnte aus diesem Grund etwas falsch sein...

Auch wenns nicht jeden schmeckt, aber ich finde es blöd das die bultins sich da hinwegsetzen dürfen. Ich sehe das auch so wie Leonidas:

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, [...]

Wobei die Begründung das es in C implementiert ist und die es deswegen dürfen keine wirkliche für mich ist und nur fadenscheinig Rechtfertigung.
...

Und vor ca. 1 Stunden war gerade das Thema in einem Thread mit dem überschrieben der builtins. Und nun wie soll man dann noch wirklich argumentieren könne? Die dürfen das und DU nicht ist ein wenig...naja ich sags mal höflich, dualistisch? Finde ich ehrlich gesagt nicht OK und auch inkonsistent.

Ist meine ehrliche Meinung.

Birkenfeld, könntest du das Thema nicht mal ansprechen? So wie ich mitgekriegt habe bist du ja auch ein wenig mit beteiligt bei Python. Könnte schwören das ich PEPs von dir gelesen habe

lg

sape hat geschrieben:Auch wenns nicht jeden schmeckt, aber ich finde es blöd das die bultins sich da hinwegsetzen dürfen. Ich sehe das auch so wie Leonidas:

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, [...]

Wobei die Begründung das es in C implementiert ist und die es deswegen dürfen keine wirkliche für mich ist und nur fadenscheinig Rechtfertigung.
...

"Dürfen" ist nicht der Punkt. Hier geht es nicht um Gesetze, die gebrochen werden können, sondern um Empfehlungen, mit denen sich der Programmierer das Leben leichter macht. In diesem Fall ist das weder für denjenigen, der print() implementiert, noch den, der es benutzt, relevant.

Und vor ca. 1 Stunden war gerade das Thema in einem Thread mit dem überschrieben der builtins. Und nun wie soll man dann noch wirklich argumentieren könne?

Das hab ich oben schon vorgeführt.

Die dürfen das und DU nicht ist ein wenig...naja ich sags mal höflich, dualistisch? Finde ich ehrlich gesagt nicht OK und auch inkonsistent.

Ich weiß nicht genau, was ich davon halten soll. Du kommst mir ehrlich gesagt etwas zwanghaft vor.

Nochmal: Das sind keine Gesetze, nicht mal Syntax oder zwingend vorgeschriebene Regeln. Du hältst dich krampfhaft an etwas fest, was es in der Form nicht gibt.

Birkenfeld, könntest du das Thema nicht mal ansprechen? So wie ich mitgekriegt habe bist du ja auch ein wenig mit beteiligt bei Python. Könnte schwören das ich PEPs von dir gelesen habe

Brav Aber nein, ich werde das Thema nicht ansprechen, zum einen weil es mich überhaupt nicht stört. Zum anderen treiben sich dort recht intelligente Menschen herum, und ich kann mir nicht vorstellen dass es keinem von denen in den Sinn gekommen ist dass "file" der Name eines Builtins ist.

birkenfeld hat geschrieben: Das hab ich oben schon vorgeführt.

birkenfeld hat geschrieben:Nochmal: Das sind keine Gesetze, nicht mal Syntax oder zwingend vorgeschriebene Regeln. Du hältst dich krampfhaft an etwas fest, was es in der Form nicht gibt.

Ok, dann werde ich mir das dann mal verinnerlichen.


Danke für die Infos.

lg

EDIT: Ups habs genau andersherum verstanden. Sry.

birkenfeld hat geschrieben:Wieso sollte `print >>file, x` schlecht sein?

Wird dabei eigentlich ein NewLine in die Datei geschrieben?

Ja, das verhält sich genau wie ``print`` ohne die Umleitung.

birkenfeld hat geschrieben:

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.

Woher hast du das python 3.0? auch wenns nur alpha is *auchwoll*
EDIT: Habs schon, danke

name hat geschrieben:Woher hast du das python 3.0? auch wenns nur alpha is *auchwoll*

Übrigens, Python 3.0 ist noch nicht einmal alpha. Alpha-Versionen von Python werden nämlich auch richtig released, mit Ankündigung auf der Hauptseite usw.

Leonidas hat geschrieben:

name hat geschrieben:Woher hast du das python 3.0? auch wenns nur alpha is *auchwoll*

Übrigens, Python 3.0 ist noch nicht einmal alpha. Alpha-Versionen von Python werden nämlich auch richtig released, mit Ankündigung auf der Hauptseite usw.

Im SVN bekomm ich immer 2.6

Man nehme den Python 3000-Branch.

svn co http://svn.python.org/projects/python/branches/p3yk