Das deutsche Python-Forum

BlackJack hat geschrieben:@NoPy: Generatoren/Iteratoren können selber wieder auf Generatoren/Iteratoren zurückgreifen.

Du kannst natürlich die Elemente von Iteratoren in Listen auffangen, aber danach hast Du natürlich andere Typen und das kann zu Problemen führen wenn die Funktion die die ursprüngliche Datenstruktur erwartet hat etwas anderes ansprechen will als die Iterierbarkeit.

BlackJack hat geschrieben:Ein weiteres Problem sind Iteratoren die verwendet werden weil die Daten in Listen zu viel Arbeitsspeicher verbrauchen würde. Bis hin zu dem Fall das man ja auch *endlose* Iteratoren haben kann, die vom Code nur teilweise ausgewertet werden, aber Deine `dump()`-Funktion weiss ja nicht wie weit sie auswerten muss/darf.

BlackJack hat geschrieben:Letztendlich verändert iterieren den internen Zustand der Objekte und es gibt keinen universellen Weg das wieder zurückzusetzen oder vorher eine 1:1 Kopie zu erstellen.

BlackJack hat geschrieben:Es werden bei Zuweisungen und Argumentübergaben *nie* Werte kopiert. Ganz einfache Regel. Dein Beispiel für Wertkopie ist keines, auch da wird nichts kopiert. Du bindest `g` zuerst an die Liste [1,2,3] und danach an die Liste [2,4,6]. Wo wurde denn da Deiner Meinung nach etwas kopiert? Wenn man einen Namen an ein Objekt bindet, hat das keinerlei Einfluss auf das Objekt das vorher vielleicht mal an diesen Namen gebunden war, und umgekehrt.

Wert1=5
Wert2=Wert1
Wert2+=1
print Wert1

Sirius3 hat geschrieben:@NoPy: alle Namen sind nur Referenzen auf Werte. Das "Wert2 += 1" ist auch eine Zuweisung und der alte Wert, an den Wert2 gebunden ist, wird durch den neuen ersetzt.

Sirius3 hat geschrieben:Bei Generatoren darfst Du einfach keine falschen Erwartungen haben, oder anders ausgedrückt, was in einer for-Schleife benutzt wird, ist nicht immer eine Liste. Du hast implizite Vorstellungen, wie etwas in Python funktioniert, was schlicht falsch ist. Wenn man die Vergänglichkeit von Generatoren akzeptiert, kann man gut damit leben.

BlackJack hat geschrieben:Falls Du Variablen als Kästen mit einem Namen ansiehst in die man einen Wert hinein tut, dann solltest Du dieses Bild ganz schnell aus dem Kopf verbannen! Das passende Bild für Python (und auch einige andere Programmiersprachen) sind Objekte auf die kleine Post-It-Zettel mit Namen geklebt werden. Eine Zuweisung nimmt also nicht etwas aus einer Box und tut es in eine andere, sondern es wird ein Zettel auf ein Objekt geklebt, der vorher eventuell auf einem anderen Objekt klebte.

#Modul A:
def a(x)...

#Modul B:
def b(x):
  A.a(x)

#Modul C:
def c(x):
  B.b(x)

if 'ABC' in dir(x) and (('DEF' in dir(x)) or ('EFG' in dir(x)):
  ...
else:
  return None

def SchmutzBeseitigen(Zimmer):
    if hatFunktion('Fegen'):
        Zimmer.Fegen(heute)
    elif hatFunktion('Wischen'):
        Zimmer.Wischen(heute)
    elif hatFunktion('Sprengen'):
        Zimmer.Sprengen(heute)
    else:
        return 'Schmutz nicht entfernbar'

def SchmutzBeseitigen2(Zimmer):
    ging = False
    if not ging:
        try:
            Zimmer.Fegen(heute)
            ging = True
        except
            pass
    if not ging:
        try:
            Zimmer.Wischen(heute)
            ging = True
        except
            pass
    if not ging:
        try:
            Zimmer.Sprengen(heute)
            ging = True
        except
            pass
    if not ging:
        return 'Schmutz nicht entfernbar'

BlackJack hat geschrieben:Die `SchmutzBeseitigen()`-Funktion ist überflüssig. Man würde einfach die `SchmutzBeseitigen()`-Methode auf `Zimmer` aufrufen. Und das Objekt entscheidet dann selber ob es sich fegt, wischt, oder sprengt. Oder etwas ganz anderes tut. Oder keine solche Methode besitzt und deshalb eine Ausnahme ausgelöst wird.

BlackJack hat geschrieben:Die beiden Varianten wären kompakter mit einer Schleife und ohne `ging` im zweiten Fall. Die Ausnahmebehandlung ist suboptimal weil da ja nicht nur `AttributeError` ”behandelt” wird, sondern jede Ausnahme einfach verschwiegen wird und es sogar vorkommen kann das mehrere der Methoden vorhanden sind und teilweise ausgeführt werden und damit vielleicht zu einem inkonsistenten Zustand von `Zimmer` führen ohne das der Aufrufer dieser Funktion das durch eine Ausnahme mitbekommt wenn mindestens eine Methode dann fehlerfrei durchläuft. Dabei dann aber schon auf einem inkonsistenten Zimmer operieren könnte.

Sirius3 hat geschrieben:@NoPy: eine Funktion sollte eine Sache machen, und nur eine. Deine Funktionen sind mach_alles-Funktionen. Niemand baut eine Maschine, die Kaffee kochen, Auto wachen, Radio spielen und Zimmer aufräumen kann. Das Problem, das Du beschreibst gibt es also nicht, wenn man sich an die Grundsätze guter Programmierung hält, die quasi für jede Programmiersprache gelten. In C würde man auch nicht alles als void* übergeben und dann raten, auf was denn der Pointer zeigt. Dort geht es nicht, weil es gar kein Mittel zur Introspektion gibt. Warum sollte man das also in Python machen wollen?

class MyMannschaftsUnterkunft(MannschaftsUnterkunft):
    def __init__(self,???):
        #wie ein Konstruktor aussehen müsste, der zuerst den geerbten Konstruktor ausführt, 
        #weiß ich im Moment nicht
        pass
        
    def SchmutzBeseitigen(self):
        #ist nur dafür da, damit Raumschiff auch mit Mannschaftsunterkunft leicht spielen kann
        self.Fegen()

class Raumschiff(objekt):
    def SchmutzBeseitigen(self,Zimmer):
        if hatFunktion('Fegen'):
            Zimmer.Fegen(heute)
        elif hatFunktion('Wischen'):
            Zimmer.Wischen(heute)
        elif hatFunktion('Sprengen'):
            Zimmer.Sprengen(heute)
        else:
            return 'Schmutz nicht entfernbar'
        
    def UeberallSchmutzBeseitigen(self):
        for Zimmer in self.AlleZimmer:
            self.SchmutzBeseitigen(Zimmer)
        self.Huelle.SchmutzBeseitigen()

    def UeberallSchmutzBeseitigen2(self):
        for Zimmer in self.AlleZimmer:
            Zimmer.SchmutzBeseitigen()
        self.Huelle.SchmutzBeseitigen()
        
    def EinfuegenZimmer(self, Zimmer):
        self.AlleZimmer.append(Zimmer) 

class Universum(objekt):
    def EinfuegenZimmerInRaumschiff(self):
        if random(3)==0:
            self.Raumschiff.EinfuegenZimmer(MyMannschaftsUnterkunft())

BlackJack hat geschrieben:@NoPy: In der Praxis benutze ich die API von den Bibliotheken die ich einbinde und versuche da nicht selber vorher und prophylaktisch irgendeine universelle API als Zwischenschicht einzuziehen. Das wird doch erst interessant wenn man die Bibliothek tatsächlich mal austauschbar machen will, was in der überwiegenden Anzahl der Fälle nie passiert.

BlackJack hat geschrieben:Und falls es dann doch sein muss kann man zu dem Zeitpunkt noch eine eine Zwischenschicht ziehen, die dann auch tatsächlich praktisch verwendet wird. Ich denke Du gehst zu theoretisch an die Sache.

BlackJack hat geschrieben:Das Problem welches Du beschreibst ist in dem Sinne dann ja auch gar nichts Python-spezifisches. Das hätte man doch in jeder Programmiersprache wenn man externe APIs benutzt die man unbedingt alle austauschbar machen möchte.

      if (
a=1000) then
                    write('Ätsch');
a.HastDuNichtGesehen(12345);