Programmiert ihr mit Python auch solche Schweinereien?
-
Bashar schrieb:
volkard schrieb:
DEvent schrieb:
IMHO nennt man das "OOP".
Polymorphie.
Dynamic Typing.
Polymorphie.
-
Basher schrieb:
Kabel Jau schrieb:
Eine Schweinerei veranstalten C++-geschädigte Leute, die überall Typprüfungen hinfrickeln wo diese nicht hingehören.
hihi, stimmt schon igendwie. statische typisierung hilft zwar fehler zu vermeiden, aber viele cpp-progger übertreiben das maßlos.
Und das schlimmste ist: wenn der python-code auf abstruse weise abschmiert, weil eine funktion dann doch mal einen komplett falschen datentyp bekommen hat (ducktyping-versagen), dann flucht man wieder, dass es keine typprüfung gibt...
-
flyhigh schrieb:
foo(boost::lexical_cast<std::string>(2)); foo("n");
Ich habe noch nie lexical_cast benutzt.
Aber foo ist auch kein gutes Beispiel. Da denkt sich jetzt jeder andere Anwendungsfälle rein, doch in wirklichkeit schreibt keiner so eine foo, und das bringt dann wenig.
-
OK, noch was zum Thema
def foo( x ): if x != "n": x = max(x,1) print(x) foo(-2) foo("n")
Ist das auch noch gutes Python, wenn ich weiß, dass foo nur mit Zahlen oder "n" aufgerufen wird.
Jetzt ist es glaub ich wirklich Dynamic Typing oder bekommt das einer mit C++ und Polymorphie hin?
-
Da bekommt man mit so wenigen Zeilen nicht in C++ hin.
Aber in keiner Sparache will man solchen Code.
-
flyhigh schrieb:
OK, noch was zum Thema
def foo( x ): if x != "n": x = max(x,1) print(x) foo(-2) foo("n")
Ist das auch noch gutes Python, wenn ich weiß, dass foo nur mit Zahlen oder "n" aufgerufen wird.
python hat doch bestimmt sowas wie typeof, instanceof, usw, oder? in abhängigkeit davon kannste ja dann in der funktion erlaubte operationen machen.
j8 schrieb:
Basher schrieb:
Kabel Jau schrieb:
Eine Schweinerei veranstalten C++-geschädigte Leute, die überall Typprüfungen hinfrickeln wo diese nicht hingehören.
hihi, stimmt schon igendwie. statische typisierung hilft zwar fehler zu vermeiden, aber viele cpp-progger übertreiben das maßlos.
Und das schlimmste ist: wenn der python-code auf abstruse weise abschmiert, weil eine funktion dann doch mal einen komplett falschen datentyp bekommen hat (ducktyping-versagen), dann flucht man wieder, dass es keine typprüfung gibt...
klar, hat beides vor- und nachteile.
-
Basher schrieb:
flyhigh schrieb:
OK, noch was zum Thema
def foo( x ): if x != "n": x = max(x,1) print(x) foo(-2) foo("n")
Ist das auch noch gutes Python, wenn ich weiß, dass foo nur mit Zahlen oder "n" aufgerufen wird.
python hat doch bestimmt sowas wie typeof, instanceof, usw, oder? in abhängigkeit davon kannste ja dann in der funktion erlaubte operationen machen.
Das tut jetzt schon so wie es ist das was ich will, auch ohne das ich ne Typprüfung einbaue.
Oder was haltet ihr von sowas
def foo( x ): liste = [7,8,9,0] if x == "n": x = len(liste) - 1 else: x = min(max(0,x), len(liste)-1) print( "0..." + str(x) ) foo(1) foo("n")
-
Mach mal ein Beispiel einer Funktion, die im weiteren Programm hilfreich sein könnte. Diese foo-Dinge sind es nicht.
Derzeit haben Diese Fragen die Qualität von "Nehmt Ihr auf Euren Jupiterflügen eigentlich Badeschlappen mit?". Manche sagen ja, manche nein, aber in Wirklichkeit weiß es keiner, weil der Fall noch nicht vorgekommen ist und auch nicht vorkommen wird.
-
def plotData( numberOfEntries ): liste = [7,8,9,0] if numberOfEntries == "all": numberOfEntries = len(liste) - 1 else: numberOfEntries = min(max(0,numberOfEntries), len(liste)-1) for i in range(0, numberOfEntries): drawValue(liste[i]) plotData(1) plotData("all")
-
In so einem Fall würde ich eher einen Funktion ohne Parameter anbieten, als da einen string zu übergeben.
-
Gab es da nicht auch Default-Argumente?
def plotData( numberOfEntries = sys.maxint ): liste = [7,8,9,0] showNumberOfEntries = min(max(0,numberOfEntries), len(liste)-1) for i in range(0, showNumberOfEntries): drawValue(liste[i]) plotData(1) plotData()
Vielleicht zerlegt man sowas. Und man gibt kaum nur eine lokale Liste aus.
def unguardedPlotData( liste , numberOfEntries ): for i in range(0, showNumberOfEntries): drawValue(liste[i]) def plotData( liste , numberOfEntries ): unguardedPlotData( liste , min(max(0,numberOfEntries), len(liste)-1) ) def plotData( liste ): unguardedPlotData( liste , len(liste)-1 ) plotData(1) plotData()
-
In python gibt es keine Funktions Überladung..
Ich würde eher zu so was tendieren:
def plotData( numberOfEntries = "" ): liste = [7,8,9,0] if numberOfEntries == "": numberOfEntries = len(liste) - 1 else: numberOfEntries = min(max(0,numberOfEntries), len(liste)-1) for i in range(0, numberOfEntries): drawValue(liste[i]) plotData(1) plotData()
Ich finde nichts zu übergeben, um alles auszugeben natürlicher, als einen (eigetnlichen sinnlosen) string übergeben zu müssen. Technisch kommt es natürlich auf das gleiche hinaus. (Wir ja schliesslich auch ein string überprüft).
-
meine version. None ist bestimmt schneller als string
def plotData( numberOfEntries = None ): liste = [7,8,9,0] if numberOfEntries == None: numberOfEntries = len(liste) - 1 else: numberOfEntries = min(max(0,numberOfEntries), len(liste)-1) for i in range(0, numberOfEntries): drawValue(liste[i]) plotData(1) plotData()
-
Also bei None oder leerem String würde ich eher keine Elemente erwarten statt alle.
Aber das war so nur ein Beispiel, eigentlich wollte ich ja wissen, ob ihr auch unterschiedliche Typen für die gleiche Variable verwendet oder den Typ sogar noch zu Laufzeit ändert?
-
flyhigh schrieb:
Also bei None oder leerem String würde ich eher keine Elemente erwarten statt alle.
Mir scheint, 'None is a common value', um NichtDaSein des Parameters anzuzeigen, also diesbezüglich Überladung nachzubilden.
-
flyhigh schrieb:
Aber das war so nur ein Beispiel, eigentlich wollte ich ja wissen, ob ihr auch unterschiedliche Typen für die gleiche Variable verwendet oder den Typ sogar noch zu Laufzeit ändert?
Duck typing: wenn die funktion auf dem Typ das richtige macht, dann darfst du den Typ auch reinstecken. Also
def exponentiate(x): """ wenn's addier- und multiplizierbar ist, sollte es auch exponierbar sein. (?) """ assert(is_from_a_compatible_algebra(x)) return complicated_formula(x) def print_nice(x): """ egal was x ist -- wenn ich's printen kann, kann ich's auch nice_printen """ print "OMGLOL--->", x, "<----!!!!" def go_warp(x, warp_factor = 9.99): """ x muss auf warp gehen können. wenn x nicht auf warp gehen kann -- ja was dann? soll ich das erst prüfen, oder den laufzeitfehler riskieren? """ if x.readyForWarp(): x.warp(warp_factor)
-
volkard schrieb:
Bashar schrieb:
volkard schrieb:
DEvent schrieb:
IMHO nennt man das "OOP".
Polymorphie.
Dynamic Typing.
Polymorphie.
Duck-Typing
-
hustbaer schrieb:
volkard schrieb:
Bashar schrieb:
volkard schrieb:
DEvent schrieb:
IMHO nennt man das "OOP".
Polymorphie.
Dynamic Typing.
Polymorphie.
Duck-Typing
MEGA QUOTE.
ähm irgendwann einig ? oder alles richtig ?
btw: hier haben ja einige was gegen C++ oder dessen Programmierer ? :p