Seite 2 von 2

Verfasst: Freitag 29. August 2008, 15:49
von pcos
Das ist jetzt ein wenig off-topic:

Ich schaue mir meinen Beitrag oben an und wunder mich, wieso da ein Smiley steht, der Satz völlig verdreht ist und eine Klammer fehlt. War ich da besoffen? Nach einiger Zeit hat's mir gedämmert: Das Zeichen "8" und darauffolgendes ")" werden als Shortcut für den Smiley interpretiert.

Und das ist einem Forum zu einer Sprache, die auf magic features pfeift! :wink:

Verfasst: Samstag 30. August 2008, 12:01
von cofi
pcos hat geschrieben: Und das ist einem Forum zu einer Sprache, die auf magic features pfeift! :wink:
Das Forum ist ja auch kein Python, sondern diese andre Sprache mit dem P ... dieses schreckliche .. ihr wisst schon ;)

Verfasst: Mittwoch 3. September 2008, 10:11
von Flo668
BlackJack hat geschrieben:@Flo668: Ich möchte noch einmal nachfragen, was denn so superpraktisch am überladen ist? In den meisten Fällen, die ich zum Beispiel aus Java kenne, kann man das in Python mit "default" Argumenten lösen.

Und da Du andere OO-Sprachen erwähnst: In Python gibt es kein "private" und Deine vielen doppelten Unterstriche riechen nach Missbrauch dieses Mechanismus. Wenn Du "private" Attribute haben möchtest, reicht ein einzelner führender Unterstrich um dies zu kennzeichnen.
"Praktisch" ist Geschmackssache. In meinem Fall war es so, dass es zwei Optionen gibt. Einerseits das Öffnen einer bestehenden Projektdatei und andererseits das neu Anlegen einer Projektdatei und darauffolgendes Öffnen.

Also bin ich her gegnagen und habe je nach Fall entschieden, welcher "Konstruktor" für diese Projektdatei eben verwendet werden soll.
Ich finde sowas praktisch, andere vielleicht nicht.

Was das mit den Strichen angeht, so habe ich nur das getan, was mir in meinem Python Lehrbuch erklärt wurde. Dort stand, dass der doppelte Unterstrich privaten Klassenattributen entsprechen würde.
Warum man bei der Konstruktion von Python auf dieses Feature dann doch verzichtet hat, wüsste ich mal gerne. Ich erinnere mich da an Informatikvorlesungen wo lang, breit und ausführlich dieses Design als eines der Herausstellungsmerkmale Objektorientierter Sprechen zelebriert wurde.

Verfasst: Mittwoch 3. September 2008, 10:28
von Leonidas
Flo668 hat geschrieben:Was das mit den Strichen angeht, so habe ich nur das getan, was mir in meinem Python Lehrbuch erklärt wurde. Dort stand, dass der doppelte Unterstrich privaten Klassenattributen entsprechen würde.
Das Buch von Galileo Computing etwa? Das Buch ist eigentlich "Java ist auch eine Insel" nur mit Python-Syntax. Nicht empfehlenswert.
Flo668 hat geschrieben:Warum man bei der Konstruktion von Python auf dieses Feature dann doch verzichtet hat, wüsste ich mal gerne. Ich erinnere mich da an Informatikvorlesungen wo lang, breit und ausführlich dieses Design als eines der Herausstellungsmerkmale Objektorientierter Sprechen zelebriert wurde.
Dieses Feature hast du in Python auch, indem du einen `_` vor die Variable setzt, womit du definierst, dass es nicht zum öffentlichen Interface der Klasse gehört. Letztendlich ist das so wie in Java auch, nur dass du dort die Reflection-API brauchst um dich an private Attribute ranzumachen, wärend du in Python einen ``_`` schreibst. Und es ist manchmal doch nützlich private Attribute zu modifizieren.

Verfasst: Mittwoch 3. September 2008, 10:28
von Rebecca
Welches Python-Buch schreibt sowas, wenn ich fragen darf?
  • In Python gibt es keine privaten Variablen oder Methoden.
  • Konvention: Attribute, auf die nicht von aussen zugegriffen werden sollte, beginnen mit einem Unterstrich: _foo.
  • Um Namenskonflikte zu vermeiden: Namen der Form __foo werden durch _klassenname__foo ersetzt:

Code: Alles auswählen

class Spam:
    __eggs = 3

Code: Alles auswählen

>>> dir(Spam)
>>> ['_Spam__eggs', '__doc__', '__module__']

Verfasst: Mittwoch 3. September 2008, 10:37
von Flo668
Leonidas hat geschrieben: Das Buch von Galileo Computing etwa? Das Buch ist eigentlich "Java ist auch eine Insel" nur mit Python-Syntax. Nicht empfehlenswert.
Nein Addison Wesley, "Peter Walerowski: Python- Grundlagen und Praxis" auf S. 116


Um nun zu verhindern, dass ein direkter Zugriff auf das Attribut (...) stattfindet, kann dies nach außen hin abgeschottet werden. Dies erreicht man durch das Voranstellen von zwei Unterstrichen (__) vor den Attributsnamen.(...). Ein solches Attribut wird auch als privat bezeichnet.


Ich kann das Buch auch aus diversen anderen Gründen nicht weiter empfehlen.

Verfasst: Mittwoch 3. September 2008, 11:05
von BlackJack
@Flo668: Wenn ich das richtig verstanden habe, kann man das sehr einfach mit einem Argument lösen:

Code: Alles auswählen

def Project(object):
    def __init__(self, filename, create_new=False):
        pass
Oder eben `True` als Vorbelegung.

Wenn es mehrere alternative "Konstruktoren" gibt, die sich nicht so einfach durch Default-Argumente "auswählen" lassen, bieten sich `staticmethod`\s bzw. `classmethod`\s an. Beispiel, ein Objekt das man laden und speichern kann, wo `load()` sozusagen ein alternativer "Konstruktor" ist:

Code: Alles auswählen

class Parrot(object):
    def __init__(self, spam, eggs=42):
        self.spam = spam
        self.eggs = eggs
    
    @classmethod
    def load(cls, filename):
        # Daten laden.
        return cls(spam, eggs)
    
    def save(self, filename):
        # Daten speichern.

Verfasst: Mittwoch 3. September 2008, 18:21
von lunar
Leonidas hat geschrieben:Letztendlich ist das so wie in Java auch, nur dass du dort die Reflection-API brauchst um dich an private Attribute ranzumachen.
Was ja per se auch nicht verwerflich ist, immerhin möchte man ja vielleicht auch mal private Methoden unittesten. Wohl aus diesem Grund funktioniert der Weg über Reflection meines Wissens auch in .NET.

Verfasst: Donnerstag 4. September 2008, 00:16
von Leonidas
lunar hat geschrieben:
Leonidas hat geschrieben:Letztendlich ist das so wie in Java auch, nur dass du dort die Reflection-API brauchst um dich an private Attribute ranzumachen.
Was ja per se auch nicht verwerflich ist, immerhin möchte man ja vielleicht auch mal private Methoden unittesten. Wohl aus diesem Grund funktioniert der Weg über Reflection meines Wissens auch in .NET.
Ja, sicher. Wirft dem Programmierer aber IMHO mehr Steine in den Weg als nötig. Im Vergleich scheint "Nutze die Reflection-API" vs. "Schreibe ein ``_`` vor den Namen" als eine eher umständliche Art das selbe zu erreichen aus. Was ich damit sagen will: beide Methoden sing gleichwertig, jedoch ist die Methode einen Bodenstrich vor den Namen zu schrieben schlichtweg unkomplizierter.

Verfasst: Montag 8. September 2008, 12:36
von Flo668
Irgendwie habe ich da ein Händchen fuer...nur verstehe ich es einfach nicht:

Code: Alles auswählen

    def _getText(nodelist):
        # usf.

     def _printData(self):
        for ce in self._list:
            print 'NEUES ELEMENT \n'
            n = ce.uri
            print self._getText(n)  

Und die Fehlermeldung:

print self._getText(n)
TypeError: _getText() takes exactly 1 argument (2 given)

...ich meine auf beiden Seiten nur eins zu zählen. Merkwürdig.

Verfasst: Montag 8. September 2008, 12:59
von Zap
Wenn du einen solchen Aufruf machst:

Code: Alles auswählen

self._getText(n)
wird dieser intern so verarbeitet

Code: Alles auswählen

MeineKlasse._getText(self, n)
Ganz einfach ;)

Deswegen müssen Methoden einer Klasse auch als erstes ein Objekt für die Klasseninstanz haben. Sonst hättest du keine Möglichkeit darauf zuzugreifen.

Verfasst: Mittwoch 10. September 2008, 07:37
von mitsuhiko
private/protected sind nirgendswo richtig abgeschottet (von PHP vielleicht abgsehen). In C++ kannst du sie dir wegcasten, in Java kann das die Reflection API und in .NET kommst du auch mit Reflection weg wenn der Code nicht mit einer Security Policy abgeschottet wurde (was afair Silverlight macht).

__ ist private, nur das viele glauben private == protected.