Kleiner Bericht zum Umstieg von Sprache xy auf Python

[cofi]

Meine bpython-Session:

Code: Alles auswählen

>>> curr = u"€"
>>> curr
u'\u20ac'
>>> print curr
€
>>> ord(curr)
8364
>>>

Das Problem ist schlicht, dass das Encoding nicht passt, d.h. deine IDLE Einstellungen passen nicht, woran es liegt kann ich dir allerdings nicht sagen, da ich IDLE grossraeumig umfahre.

Ja, Klassenvariablen sind mit Java `static` vergleichbar, allerdings sollte man sich hueten Vergleiche mit statischen Sprachen staendig heranzuziehen, da das eine andere Welt ist. In Python gibt es - wie schon haeufig angesprochen - keine Deklarationen, sondern nur ausfuehrbaren Code. Ebenfalls keine Qualifier. Das sollte man versuchen zu verstehen und nicht auf Sprachen ausweichen, die das nicht kennen.

Warum Tupel und Listen? Die einfachste Antwort duerfte sein, dass die Sprache reichlich Tupel verwendet. Die naechste Stufe, dass sie effizienter implementiert werden koennen als Listen.
Fuer mich kommt dazu noch die semantische Ebene und so den Source verstaendlicher machen koennen.

[Darii]

Wieso kommt IDLE nicht mit ord() klar, wenn doch utf-8 eingestellt ist? Und wieso wird das Euro-Zeichen beim print nicht ausgegeben?

Weil da irgendwas kaputt ist, von IDLE hört man hier sowieso immer nur die wildesten Sachen, also lieber nicht benutzen. Dasselbe Problem habe ich aber auch mit ipython unter OSX(ipython ist unter OSX sowieso immer etwas broken, liegt vermutlich an readline/libedit). Ich behelfe mich mit "€".decode("utf8").

Sorry, hab mich unklar ausgedrückt. Richtig ist aber doch, dass staticvarA und staticvarB Klassenvariablen sind?! Da Klassenvariablen z.B in Java mit static deklariert werden, neige ich meisst dazu, sie mit "statische Variablen" zu bezeichnen.

Ja. Allerdings sind statische Variablen und Methoden etwas anderes als Klassenmethoden und -variablen. Klassenmethoden operieren auf dem Klassenobjekt. Statische Methoden in Java sind allerdings wirklich nur Funktionen. Die Klasse steht in statischen Methoden nicht als this zur Verfügung. Späße wie Vererbung funktionieren deswegen nicht wirklich gut mit statischen Methoden.

[Leonidas]

Ich muss sma da jetzt aber auch beipflichten -- dem Einsteiger ist jetzt nicht geholfen, dass wir uns über Details unterhalten was jetzt hashbar ist und was nicht oder wie sich das auf die Objektidentität auswirkt.

[mechanicalStore]

Ich muss sma da jetzt aber auch beipflichten -- dem Einsteiger ist jetzt nicht geholfen, dass wir uns über Details unterhalten was jetzt hashbar ist und was nicht oder wie sich das auf die Objektidentität auswirkt.

Nee nee, das ist kein Problem. Während man aus der Doku ohnehin nur Dinge wie die Syntax und Semantik erfährt, sind solche Diskussionen durchaus nützlich, um Weiteres über das Verhalten von Python zu erfahren, man (ich) kann also nur daraus lernen.

@lunar:

Code: Alles auswählen

class Foo(object):
    def __init__(self, x):
        self.value = x
    def __hash__(self):
        return hash(self.value)
    def __eq__(self, other):
        return self.value == other.value
    def __ne__(self, other):
         return self.value != other.value

f = Foo('hallo')
d = {f: 'welt'}
f.value = 'tschüss'
d[f] # <-- ergibt KeyError, weil sich der Hash von f geändert hat

Mir ist nicht ganz klar, was hier passiert. __init__ ist mir ja schon bekannt. Sind die anderen Funktionen ebenfalls Standard und werden hier überschrieben?
Was genau bewirkt die Anweisung d = {f: 'welt'}, das ist eine mir sehr unbekannte Syntax.

Schönen Gruß

[DasIch]

@mechanicalStore Methodennamen die mit zwei Unterstrichen beginnen und enden, bezeichnen sogenannte Special Methods, die werden im Data model erklärt.

Dort findest du außerdem Erklärungen zur Implementation von Deskriptoren etc.

In Zeile 13 des Codes wird ein Dictionary erstellt und an einen Namen gebunden, f dient dabei als Schlüssel für den Wert 'welt'.

[cofi]

Während man aus der Doku ohnehin nur Dinge wie die Syntax und Semantik erfährt, sind solche Diskussionen durchaus nützlich, um Weiteres über das Verhalten von Python zu erfahren, man (ich) kann also nur daraus lernen.

Zur Doku gehoert auch die Sprachspezifikation, alles was dort nicht enthalten ist, sollte sowieso mit Vorsicht zu geniessen sein, da hoechstwahrscheinlich Implementierungsdetail von CPython. Wobei man so natuerlich auf die Hintergruende schliessen (lese: raten) kann.

Die Dunder (double underscore) Attribute sind "magic". Im Klartext heisst das, dass das spezielle Methoden sind, die der Interpreter als solche erkennt die einem Objekt spezielle Eigenschaften verpassen, sozusagen Protokolle/Interfaces.

Mehr Infos: http://docs.python.org/reference/datamo ... thod-names
http://www.ironpythoninaction.com/magic-methods.html

Was genau bewirkt die Anweisung d = {f: 'welt'}, das ist eine mir sehr unbekannte Syntax.

Auf der rechten Seite ist ein Dictionary Literal und der rest ist eine Zuweisung. Der Kern des Snippets ist natuerlich, dass `f` hier hashable scheint - `__hash__` implementiert - es aber nicht wirklich ist.

[Edit (Leonidas): Restliche Diskussion zu Tupeln und Listen in Hashable objects abgetrennt]

[Rebecca]

Ach und mein Rant gegen das `-*-`: Ich weigere mich auch in Zukunft, ich in meinen Quelltext Beschwörungsformeln für archaische Editoren einzubauen, nur weil jemand nicht UTF-8 als längst überfälligen Standard akzeptieren kann.

In Emacs ist utf-8 Standard... Aber darum ging es in BlackJacks Antwort ja auch nicht.

[sma]

Was genau bewirkt die Anweisung d = {f: 'welt'}, das ist eine mir sehr unbekannte Syntax.

Das steht für

Code: Alles auswählen

d = {}
d[f] = 'welt'

#oder
d = dict()
d[f] = 'welt'

Links vom ":" ist der Schlüssel, rechts davon der Welt. Beides könnten beliebige Objekte sein, allerdings hat man - wie hier ja zu genüge erläuert - wenig Freude daran, wenn das Schlüsselobjekt veränderbar, aber nicht "hashable" ist. Und damit kommen wir zu einer der ursprünglichen Fragen zurück: Warum es sinnvoll ist, dass Objekte unveränderbar sind. Dann haben sie in der Regel (wenn sie auch nur unveränderbare Objekte enthalten) einen vernünftigen Hash-Wert und können al Schlüssel in einem Dictionary benutzt werden.

Stefan

[mechanicalStore]

Das steht für

Code: Alles auswählen

d = {}
d[f] = 'welt'

#oder
d = dict()
d[f] = 'welt'

Links vom ":" ist der Schlüssel, rechts davon der Welt. Beides könnten beliebige Objekte sein, allerdings hat man - wie hier ja zu genüge erläuert - wenig Freude daran, wenn das Schlüsselobjekt veränderbar, aber nicht "hashable" ist. Und damit

Das macht es klarer, vielen Dank. Der Doppelpunkt hatte mich verwirrt. Nun habe ich mal eine andere Frage; Unter http://www.tortall.net/mu/wiki/CairoTutorial gibt es ein Beispiel, dessen Code ich mal teilweise poste:

Code: Alles auswählen

#! /usr/bin/env python
import cairo
from math import pi, sqrt

class Diagram(object):
    def __init__(self, filename, width, height):
        self.surface = cairo.SVGSurface(filename + '.svg', width, height)
        cr = self.cr = cairo.Context(self.surface)

        cr.scale(width, height)
        cr.set_line_width(0.01)

        cr.rectangle(0, 0, 1, 1)
        cr.set_source_rgb(1, 1, 1)
        cr.fill()

**      self.draw_dest(cr)

        cr.set_line_width( max(cr.device_to_user_distance(2, 2)) )
        cr.set_source_rgb(0, 0, 0)
        cr.rectangle(0, 0, 1, 1)
        cr.stroke()

        self.surface.write_to_png(filename + '.png')
        cr.show_page()
        self.surface.finish()

class SetSourceRGBA(Diagram):
    def draw_dest(self, cr):
        cr.set_source_rgb(0, 0, 0)         #rgba
        cr.move_to(0, 0)                   #rgba
        cr.line_to(1, 1)                   #rgba
        .....

if __name__ == '__main__':
    size = 120
    SetSourceRGBA('setsourcergba', size, size)

Frage zur letzten Zeile: Wird hier die Klasse tatsächlich "nur" als Funktion aufgerufen (da keine Instanzierung stattfindet)? Wie aber kann man dann self benutzen?

Wird durch diesen Aufruf automatisch die __init__ Methode der Basisklasse (Diagram) aufgerufen (ich frage, weil ich meine mich zu erinnern, dass irgendwo gesagt wurde, dass das nicht so ist und man sich selbst darum kümmern muss, dass der Konstruktor der Basisklasse aufgerufen wird)?

Ist es nicht sehr unsauber, im Konstruktor der Basisklasse in der Zeile ** eine Methode der erbenden Klasse aufzurufen?

Bedeutet folgende Zeile im Kontruktor

Code: Alles auswählen

cr = self.cr = cairo.Context(self.surface)

dass self.cr eine Instanzvariable und cr eine Klassenvariable ist? Falls ja, hätte man in dem Fall cr nicht auf der (Einrück)-Ebene im Hauptblock (also auf der Ebene, wo auch __init__ deklariert wurde) deklarieren müssen?

Schönen Gruß

[numerix]

Frage zur letzten Zeile: Wird hier die Klasse tatsächlich "nur" als Funktion aufgerufen (da keine Instanzierung stattfindet)? Wie aber kann man dann self benutzen?

Doch, hier wird ein Exemplar von SetSourceRGBA erzeugt, aber dieses wird an keinen Bezeichner gebunden.

Wird durch diesen Aufruf automatisch die __init__ Methode der Basisklasse (Diagram) aufgerufen (ich frage, weil ich meine mich zu erinnern, dass irgendwo gesagt wurde, dass das nicht so ist und man sich selbst darum kümmern muss, dass der Konstruktor der Basisklasse aufgerufen wird)?

Letzteres gilt nur dann, wenn eine Klasse eine eigene __init__()-Methode hat. Hat sie keine (so wie hier), wird automatisch diejenige der Basisklasse verwendet.

Bedeutet folgende Zeile im Kontruktor

Code: Alles auswählen

cr = self.cr = cairo.Context(self.surface)

dass self.cr eine Instanzvariable und cr eine Klassenvariable ist?

Nein, cr ist eine lokale Variable.

[jbs]

SetSourceRGBA erbt von Diagram und Diagram hat eine __init__, die aufgerufen wird.

`cr = self.cr = cairo.Context(self.surface)` bewirkt, dass das Objekt sowol an das Objekt gebunden wird als auch als kurzer Name (cr) zur Verfügung steht. Da war wohl jemand zu faul immer self.cr zu schreiben.

[/me]

Wird durch diesen Aufruf automatisch die __init__ Methode der Basisklasse (Diagram) aufgerufen (ich frage, weil ich meine mich zu erinnern, dass irgendwo gesagt wurde, dass das nicht so ist und man sich selbst darum kümmern muss, dass der Konstruktor der Basisklasse aufgerufen wird)?

Wenn die abgeleitete Klasse keine __init__-Methode hat, dann wird die der Basisklasse aufgerufen. Hätte die abgeleitete Klasse eine solche Methode so würde die der Basisklasse nur aufgerufen, wenn das in der abgeleiteten Klasse so programmiert wäre.

Ist es nicht sehr unsauber, im Konstruktor der Basisklasse in der Zeile ** eine Methode der erbenden Klasse aufzurufen?

Nein. Zumindest ich sehe das nicht als problematisch an, sondern eher als das, was Objektorientierung mit ausmacht.

Bedeutet folgende Zeile im Kontruktor

Code: Alles auswählen

cr = self.cr = cairo.Context(self.surface)

dass self.cr eine Instanzvariable und cr eine Klassenvariable ist?

Nein. cr ist nur im Konstruktor bekannt.

[cofi]

Ist es nicht sehr unsauber, im Konstruktor der Basisklasse in der Zeile ** eine Methode der erbenden Klasse aufzurufen?

Nein. Zumindest ich sehe das nicht als problematisch an, sondern eher als das, was Objektorientierung mit ausmacht.

Das mag sein, aber da man direkt Klassen von `Diagram` erstellen kann, finde ich das durchaus unsauber.
IMHO sollte man ein `draw_dest` in `Diagram` erstellen, das einen `NotImplementedError` schmeisst oder vergleichbares.

[Darii]

Frage zur letzten Zeile: Wird hier die Klasse tatsächlich "nur" als Funktion aufgerufen (da keine Instanzierung stattfindet)?

Wieso sollte keine Instanzierung stattfinden? Wie sma schon schrieb, eine Klasse gibt, wenn man sie „wie eine Funktion aufruft“ eine Instanz von sich selbst zurück(das Verhalten ließe sich natürlich ändern, da Klassen auch nur Objekte wie alle anderen sind). Wie genau das geschieht, kann dir erstmal egal sein.

Ist es nicht sehr unsauber, im Konstruktor der Basisklasse in der Zeile ** eine Methode der erbenden Klasse aufzurufen?

Jein, dass macht deine Klasse nur schlicht und ergreifend zu einer abstrakten Klasse. Aber wie schon geschrieben, wäre es besser, die Methode in der Basisklasse zu implementieren und einen NotImplementedError zu werfen, das macht die Fehlermeldungen aussagekräftiger bzw. man man ggf. besser auf den Fehler reagieren.

Code: Alles auswählen

cr = self.cr = cairo.Context(self.surface)

dass self.cr eine Instanzvariable und cr eine Klassenvariable ist? Falls ja, hätte man in dem Fall cr nicht auf der (Einrück)-Ebene im Hauptblock (also auf der Ebene, wo auch __init__ deklariert wurde) deklarieren müssen?

cr ist eine stinknormale lokale Variable. Es gibt keinen Grund, warum das nicht so sein sollte. Warum

Warum er das überhaupt macht, liegt daran, dass Attributzugriffe in Python relativ teuer sind. Wenn eine Funktion oft aufgerufen wird kann schon Zeit sparen, wenn man dort oft verwendete Attribute lokal „cached“. Man sollte das aber auch nicht überstrapazieren(premature optimization...)

[jbs]

oh, ich wollte auch lokal schreiben.

[mechanicalStore]

Ist es nicht sehr unsauber, im Konstruktor der Basisklasse in der Zeile ** eine Methode der erbenden Klasse aufzurufen?

Jein, dass macht deine Klasse nur schlicht und ergreifend zu einer abstrakten Klasse. Aber wie schon geschrieben, wäre es besser, die Methode in der Basisklasse zu implementieren und einen NotImplementedError zu werfen, das macht die Fehlermeldungen aussagekräftiger bzw. man man ggf. besser auf den Fehler reagieren.

Wenn man die Klassen aber in einzelne Module trennen würde, wäre es doch im Sinne der Objektorientierung fatal, dass die Basisklasse mit dem Aufruf von drawTest abhängig davon wird, ob/dass eine Vererbung stattfindet, ob nun mit oder ohne NotImplementedError, oder?

Code: Alles auswählen

cr = self.cr = cairo.Context(self.surface)

dass self.cr eine Instanzvariable und cr eine Klassenvariable ist?

cr ist eine stinknormale lokale Variable. Es gibt keinen Grund, warum das nicht so sein sollte. Warum er das überhaupt macht, liegt daran, dass Attributzugriffe in Python relativ teuer sind. Wenn eine Funktion oft aufgerufen wird kann schon Zeit sparen, wenn man dort oft verwendete Attribute lokal „cached“. Man sollte das aber auch nicht überstrapazieren(premature optimization...)

Ok, ich ging von Java (oder auch C#) aus, wo "lokale" Variablen innerhalb einer Klassendeklaration ein implizites "this." erhalten. Verglichen hiermit gäbe es dann self.cr doppelt. Aber da weicht Python wohl stark von ab (wie ja auch schon gesagt wurde, ist Java als Vergleich ungeeignet).

Schönen Gruß

[Darii]

Wenn man die Klassen aber in einzelne Module trennen würde, wäre es doch im Sinne der Objektorientierung fatal, dass die Basisklasse mit dem Aufruf von drawTest abhängig davon wird, ob/dass eine Vererbung stattfindet, ob nun mit oder ohne NotImplementedError, oder?

Nein, deswegen gibt es ja abstrakte Klassen/Methoden(auch in Java). Und seit Python 2.6 gibt es auch Möglichkeiten, das Ganze in geregelte Bahnen zu lenken

Ok, ich ging von Java (oder auch C#) aus, wo "lokale" Variablen innerhalb einer Klassendeklaration ein implizites "this." erhalten. Verglichen hiermit gäbe es dann self.cr doppelt. Aber da weicht Python wohl stark von ab (wie ja auch schon gesagt wurde, ist Java als Vergleich ungeeignet).

Nein das tun sie auch in Java oder C# nicht. Variablen die man in Methoden deklariert werden nicht automatisch Instanzvariablen.

[mechanicalStore]

Nein das tun sie auch in Java oder C# nicht. Variablen die man in Methoden deklariert werden nicht automatisch Instanzvariablen.

Sorry, was Methoden betrifft, hast Du natürlich Recht! Ich habe etwas durcheinander gebracht, ist doch recht ungewohnt, wenn keine Variable explizit deklariert wird. Gibt es bei Python ein "use strict" a'la Perl?

Schönen Gruß

[BlackJack]

@mechanicalStore: Nein so etwas wie "use strict" gibt es nicht, aber das würde ja auch keinen Sinn machen, weil es in Python ausser ``global`` keine Deklarationen gibt.

Ich finde das Cairo-Beispiel übrigens nicht schön weil eine Klasse als Funktion missbraucht wird. So etwas versuche ich zumindest zu vermeiden.