Typinformation im sNamen - Pro/Contra
Verfasst: Mittwoch 19. September 2007, 21:36
## Entstanden aus Thread "--->Kartenspiel programmieren<----"
## siehe http://www.python-forum.de/topic-12002.html
Hallo BlackJack!
Trotzdem kann man den Typ eines ganz speziellen Objekts festlegen und den Namen in seinem Code entsprechend gestalten.
Und läuft ein Programm nach einem Patch nicht mehr, weil das Argument die inzwischen verwendete (Listen-)Funktion nicht unterstützt, dann war der l-Hinweis auch nicht umsonst.
Wie gesagt, wenn man sich nicht sicher ist, ob ein Wert vom Typ float oder int ist, muss man das Präfix nicht davorsetzen. Das ist für die Variablen bestimmt, die einen festgelegten Typ haben sollen.
Nochmal: es geht darum, einen neuen Code zu überfliegen und dort systematisch auf erste Fehler aufmerksam zu werden. Z.B. bei Anfragen hier im Forum, wo man nicht immer die Möglichkeit hat, gleich zu testen.
Auf die Gefahr hin, dass ich mich wiederhole: wenn man sich nicht festlegen will, braucht man das nicht zu tun!
Für mich ist ein Code wesentlich besser lesbar, wenn ich mir nicht von diversen Namen den aktuellen Typ merken muss, sondern ihn am Namen ablesen kann.
Gruß,
Michael
## siehe http://www.python-forum.de/topic-12002.html
Hallo BlackJack!
Das Prinzip des "duck typing" würde ich so interpretieren, dass der Typ eines Objekts egal ist, solange die benötigten Methoden und Variablen zur Verfügung stehen. Aber das betrachte ich nur an Schnittstellen als sinnvoll, wenn man Argumente empfängt. Wenn man nicht unbedingt eine Liste erwartet, kann man sich das auch offen halten, indem man das Naming für allgemeine Objekte verwendet (Cap-Case).BlackJack hat geschrieben:@Michael Schneider: Den Typ in einer dynamischen Sprache im Namen zu kodieren ist einfach irreführend und läuft dem "duck typing" zuwieder.
Trotzdem kann man den Typ eines ganz speziellen Objekts festlegen und den Namen in seinem Code entsprechend gestalten.
Und läuft ein Programm nach einem Patch nicht mehr, weil das Argument die inzwischen verwendete (Listen-)Funktion nicht unterstützt, dann war der l-Hinweis auch nicht umsonst.
Richtig. Und was meinst Du dann mit:BlackJack hat geschrieben:zu 2) Damit hast Du ein komplett anderes Objekt und damit auch die Bedeutung verändert. Das sollte sich natürlich auch im Namen wiederspiegeln.
Wenn ich in meiner Funktionsdefinition durch das l-Präfix angebe, dass ich ein Objekt erwarte, welches die Listen-Schnittstelle unterstützt, dann kann das entsprechend "Duck Typing" auch jedes Objekt sein, das das gewährleistet.wenn man den Typ mal ändern sollte und nicht die Namen anpasst.
Wie gesagt, wenn man sich nicht sicher ist, ob ein Wert vom Typ float oder int ist, muss man das Präfix nicht davorsetzen. Das ist für die Variablen bestimmt, die einen festgelegten Typ haben sollen.
Das sieht man dann aber schon bei der Zuweisung, z.B.BlackJack hat geschrieben:zu 3) Das eine nicht vorhandene Methode aufgerufen wird, kann man nur zur Laufzeit feststellen, egal wie der Name aussieht. Das findet man durch Tests, die man sowieso machen muss, weil kein Name garantiert das bei `lNamen` *wirklich* eine Liste an den Namen gebunden ist.
Code: Alles auswählen
sNamen = sZeile.split()
Um den Umfang der genutzten Funktionalität sollte man sich vor dem Coden Gedanken machen. Denn ob eine Liste wirklich in jedem Fall später durch ein Tupel ersetzt werden kann, ist nicht immer vorauszusehen.BlackJack hat geschrieben:Desweiteren will man das in der Regel auch gar nicht so festlegen. An `lKarten` kann man eine Liste binden. Wenn gar nicht die ganze `list()`-API benötigt wird, kann es aber günstiger sein ein Tupel, ein `set()` oder vielleicht ein Objekt vom Typ `Talon` oder `Hand` zu binden ohne das sich am Programm etwas ändert. Nur ist der Name `lKarten` dann "falsch", also irreführend.
Auf die Gefahr hin, dass ich mich wiederhole: wenn man sich nicht festlegen will, braucht man das nicht zu tun!
Für mich ist das dasselbe, nur in grün. Von mir aus nennen wir es Typinformation.BlackJack hat geschrieben:Was Du da so ein bisschen über Namenskonvention einführen willst, ist statische Typinformation.
Und genau so ist das auch. Warum sollte man Typfehler nur in Java vorher erkennen können? Python ist nicht dadurch Python, dass man den Typ nicht vom Namen ablesen kann, wenn man ihn schon kennt.BlackJack hat geschrieben:Mit den gleichen Argumenten wollen ja immer wieder Leute Python zu Java machen. "Aber dann kann man ja schon vorher Typfehler erkennen"…
Für mich ist ein Code wesentlich besser lesbar, wenn ich mir nicht von diversen Namen den aktuellen Typ merken muss, sondern ihn am Namen ablesen kann.
Gruß,
Michael