Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
legargeomatrix hat geschrieben:
Ja, dass es auch ohne geht ist mir klar, doch das Projekt wird auch dazu dienen, OOP zu unterrichten, darum die strikte OOP-Schreibweise.
Was haben denn getter und setter mit OOP zu tun? *wunder*
Wie gesagt, bei Java, C# (afaik) und C++ ist das sicher ok. Aber bei Sprachen ohne Zugriffsschutzmechanismen benötigen so etwas nun einmal nicht! Wieso also etwas falsches* lehren?
legargeomatrix hat geschrieben:Ja, dass es auch ohne geht ist mir klar, doch das Projekt wird auch dazu dienen, OOP zu unterrichten, darum die strikte OOP-Schreibweise.
Nur weil man in Java für jeden Mist getter und setter braucht, ist das doch noch nicht DIE OOP-Schreibweise. Python zeigt doch gerade, dass es auch einfacher und eleganter geht. Oder willst du mit diesem Python-Programm eine Einführung in OOP für Java geben ...
@legargeomatrix: Wenn man mit 10⁷ Objekten arbeitet sollte man halt auch damit leben dass das etwas dauert.
Die Getter und Setter haben nichts mit OOP zu tun und wenn Du für ein Attribut *beides* hast, dann ist das totaler Unsinn weil es vom Effekt das selbe ist wie gleich auf das Attribut direkt zuzugreifen.
In Java macht man diesen Blödsinn statt einfach das Feld ``public`` zu deklarieren, weil man sich sonst später nicht umentscheiden kann einen "berechneten" Zugriff durchzuführen, ohne das sich Quelltext bei den ganzen vorhandenen Zugriffen auch ändern muss. Dieses Problem gibt es Python aber nicht -- dafür ist `property()` da. In Python machst Du Dir also nur völlig unnötige Schreibarbeit die den Quelltext ohne Mehrwert aufbläht und die Laufzeit verlangsamt.
Und wenn Du schon so auf OOP Wert legst, solltest Du Dir die erste Zeile in `delete()` vielleicht noch einmal überlegen ob das wirklich so toll ist die Polymorphie an der Stelle auszuhebeln in dem `Knoten.get_vater()` verwendet wird, egal von welchem Typ `self` wirklich ist. Du setzt da auch `self.kinder` auf eine leere Liste -- allerdings haben die Kinder ja wahrscheinlich einen Verweis auf *diesen* Knoten und der bleibt -- ist das okay?
numerix hat geschrieben:@Darii: Dein gezeigter Code ist gar nicht lauffähig ...
Meine Güte, dann Pack halt noch nen xrange ums len.
Aber im Ernst: "massiv schneller" wird das dadurch nicht.
Der Flaschenhals ist hier auch nicht das Befüllen oder Anhängen an die Liste, sondern die vielen Instanzbildungen.
Interessant woran das vorhin lag, bei mir kamen vorhin 10 Sek raus, jetzt ist es gleich, muss das morgen nochmal prüfen. Ehrlich gesagt erstaunt es mich, dass append so schnell ist.
import numpy
t = clock()
f1 = [None] * 1000000
for i in xrange(1000000):
f1[i] = i
print clock() - t
t = clock()
f2 = []
for i in xrange(1000000):
f2.append(i)
print clock() - t
t = clock()
f3 = numpy.empty(1000000)
for i in xrange(1000000):
f3[i] = i
print clock() - t
BlackJack hat geschrieben:@legargeomatrix: Wenn man mit 10⁷ Objekten arbeitet sollte man halt auch damit leben dass das etwas dauert.
Die Getter und Setter haben nichts mit OOP zu tun und wenn Du für ein Attribut *beides* hast, dann ist das totaler Unsinn weil es vom Effekt das selbe ist wie gleich auf das Attribut direkt zuzugreifen.
In Java macht man diesen Blödsinn statt einfach das Feld ``public`` zu deklarieren, weil man sich sonst später nicht umentscheiden kann einen "berechneten" Zugriff durchzuführen, ohne das sich Quelltext bei den ganzen vorhandenen Zugriffen auch ändern muss. Dieses Problem gibt es Python aber nicht -- dafür ist `property()` da. In Python machst Du Dir also nur völlig unnötige Schreibarbeit die den Quelltext ohne Mehrwert aufbläht und die Laufzeit verlangsamt.
Und wenn Du schon so auf OOP Wert legst, solltest Du Dir die erste Zeile in `delete()` vielleicht noch einmal überlegen ob das wirklich so toll ist die Polymorphie an der Stelle auszuhebeln in dem `Knoten.get_vater()` verwendet wird, egal von welchem Typ `self` wirklich ist. Du setzt da auch `self.kinder` auf eine leere Liste -- allerdings haben die Kinder ja wahrscheinlich einen Verweis auf *diesen* Knoten und der bleibt -- ist das okay?
class Knoten(object):
"""Knoten-Klasse fuer die Knoten des Spielbaums"""
def __init__(self, stellung, vater, tiefe):
self.stellung = stellung
#die Tiefe entspricht der Runde, in der der Knoten gespielt wurde
self.tiefe = tiefe
self.kinder = []
self.vater = vater
self.bewertung = None
self.blatt = False
#ersetzt del self, denn die pointers muessen entfernt werden
def delete(self, spielbaum):
for kind in self.kinder:
kind.vater = None
self.kinder = []
self.vater.kinder.remove(self)
spielbaum.remove(self)
return spielbaum
Mein Hauptcode sieht damit übrigens auch besser aus
legargeomatrix hat geschrieben:Ja, dass es auch ohne geht ist mir klar, doch das Projekt wird auch dazu dienen, OOP zu unterrichten, darum die strikte OOP-Schreibweise.
Es ist die Frage was man unterrichten will.
Auch ohne Getter und Setter ist es objektorientiert und warum der zusätzliche Overhead zu besserem und effektiverem Code führen soll ist mir nicht wirklich klar. Wenn zusätzliche Funktion gefordert wird, dann ist mir das klar, aber selbst das lässt sich, wenn eine Änderung in diese Richtung erst nach einiger Zeit gewünscht wird, hervorragend über den @property-Decorator abhandeln.
@legargeomatrix: Ist `blatt` nicht irgendwo redundant? Das ist doch dann der Fall wenn `kinder` leer ist, oder? Also würde ich da entweder eine Testmethode für schreiben und `blatt` weglassen oder das Attribut entsprechend als `property()` definieren. Als Testmethode:
Und wenn's "pythonisch" sein soll machen auf Knoten-Objekten IMHO `__len__()` für die Anzahl der Kinder und `__iter__()` zum Iterieren über die Kinder Sinn.