if __name__ == "__main__":
    main()

Es gibt bestimmte feste Variable intern in Python, die mit doppelte Unterstrichen vor und nach dem Namen markiert sind. Eine davon ist __name__, und wenn man das Skript von der Kommandozeile aufruft, ist diese Variable auf “__main__” gesetzt. Auch wenn man das Skript einfach runterschreiben könnte, ist es besser, das so zu schreiben und die Funktionalität in einer Funktion main() zu definieren, und diese wie hier aus dem if aufzurufen. So kann man die Wiederverwendbarkeit des Codes erhöhen.

Ok, wir möchten folgendes ausprobieren: Wir haben eine einfache Klasse Testobject, die sehen wir uns mal zuerst an:

class TestObject:
    
    def __init__(self, value, text=""):
        self.value = value
        self.text = text

    def output(self):
        print self.value, self.text

Die Klassendefinition ist einfach. Die Funktion, die __init__ heißt, ist der Konstruktor. Man sieht auch, dass Klassenfunktionen als erstes Argument self haben müssen. Es werden zwei Klassenvariablen value und text angelegt. Man sieht auch im Funktionaufruf, dass text optional ist, weil es einen Default-Wert hat. Es gibt weitere dieser vorgegebenen Funktionsnamen mit dem __, für Getters und Setters, auch für das ausgeben, aber hier haben wir doch eine eigene Funktion output dafür. Man kann einfach print schreiben und dann Variablen durch Komma hintendranreihen, das schafft er dann, das in einen String zu wandeln und setzt auch automatisch Leerzeichen dazwischen und Zeilenumbrüche ans Ende.

Also mit output kann man value und text des Objektes ausgeben.

Das ganze Skript macht jetzt folgendes: Es legt eine Liste an mit drei Elementen. Dann soll die Funktion doubleList die Anzahl der Elemente verdoppeln, in dem es jedes kopiert, aber bei der Kopie den Wert um eins hochzählt. Aber wenn man die Ausgabe ansieht, fällt auf dass die Objekte nicht kopiert in die Liste eingefügt werden, sondern nur als Referenz.

2

2

6 Hallo

6 Hallo

11 ScienceBlogs

11 ScienceBlogs

Die Zahlen sind gleich, das heißt er hat nur eine Kopie des Objektes, und diese einmal bearbeitet.

So, jetzt ist der Beitrag mit Python-Ranting schon ein bißchen lang geworden, daher mache ich mal Schluss für heute. Im nächsten Teil geht es dann wirklich an die wissenschaftlichen Bibliotheken um SciPy, und vielleicht später auch nochmal systematischer etwas zu Python.

Zur Einführung in die vielfältigen Funktionen von Python empfehle ich das Buch “Dive Into Python” von Mark Pilgrim, das man auch <a href=”https://www.diveintopython.org/>online</a> lesen kann.

1 / 2

Kommentare (10)

  1. #1 Bernd
    03/29/2009

    Fein, danke! Selbst unter der Annahme, dass es solche Beiträge (oder “Topologie von Flächen $” von Thilo Kuessner, meine 3 Semester Mathe liegen dafür zu lang zurück…) nicht in die Spitze der Top5 schaffen, gehören sie unbedingt dazu, um den SB so etwas wie wissenschaftliche street credibility zu verschaffen (IMHO).

    Zurück zum Beitrag: Allerdings muss ich für mich feststellen, dass ich nach ein wenig Beschäftigung mit Python + SciPy noch kein Argument gefunden habe, das mir gegenüber R einen Zusatzgewinn verspricht. Deswegen erwarte ich mit Spannung die weiteren Ausführungen der kleinen Reihe.

  2. #2 Jörg
    03/29/2009

    Mit R habe ich selbst noch nichts gemacht, aber jetzt wo ich auch mit Monte Carlo-Methoden arbeite, wäre das vielleicht sogar eine Überlegung wert, mir das anzusehen. Ich denke, Python + SciPy (und es gibt ja noch viele weitere Module) gehen mehr in die Breite und bieten allgemein eine solide Basis für jede Anwendung. R ist da sicherlich in der Spezialisierung auf Statistik besser, vermute ich?

  3. #3 Markus
    03/29/2009

    Ich bin gerade dabei mich in Python 3 einzuarbeiten, gefällt mir bisher sehr gut. Allerdings ist es nicht mehr mit früheren Versionen kompatibel und an einigen Stellen wurde der Syntax verändert. Dein Problem mit /2. gibt es nicht mehr.
    Dadurch habe ich noch einige Schwierigkeiten mit den Tutorials, die auf 2.x ausgelegt sind.

  4. #4 Martin
    03/30/2009

    R hat den Vorteil, dass es mit CRAN ein riesiges Repository an Programmpaketen gibt, die größtenteils Statistik-spezifisch sind. Bei einer oberflächlichen Suche habe ich zB acht Pakete gefunden, die irgendwas mit Monte Carlo-Methoden zu tun haben.

  5. #5 A.S.
    03/30/2009

    R und Python brauchen nicht gegeneinander zu konkurrieren, sie arbeiten perfekt zusammen.

  6. #6 Jannis
    03/30/2009

    “Grundsätzlich gehe ich von Linux aus, alles andere taugt nicht.”
    Ich weiss, es ist eine Glaubensfrage, aber Mac OS ist eine Unix-Platform wie jede andere auch (mit Shell und allem was man braucht). Python läuft wunderbar und ist ab 10.5 sogar schon standardmässig vorinstalliert. Ich kann also alle Mac-User nur ermuntern, es zu benutzen. Das nur als Ergänzung – tolle Idee, hier einen kleinen Schnupperkurs zu machen!

  7. #7 Engywuck
    03/30/2009

    Ist Python schnell genug für wirklich große Datensätze?
    Ein Freund von mir wollte zuerst für seine Diplomarbeit was in Perl schreiben (n paar Jährchen her), ist dann aber doch zu C gewechselt, weils sonst zu lange dauerte (im Endeffekt einige hundert Milliarden Daten auf Eingangsseite). Und auch ich stand schon vor dem Problem, dass Perl bei einigen zehn Millionen Datensätzen (Wochenendmessung eunes Sensors jede zehntel Sekunde auf 30 Kanälen…) doch recht lange verweilte… gut, war in meinem Fall nur ne Kaffeepause, da recht einfache Umrechnerei 😀

    Oder sind das nur klassische Vorurteile gegenüber Skriptsprachen, die Python nicht hat?

  8. #8 A.S.
    03/30/2009

    Jannis,

    Mac OS ist eine Unix-Platform wie jede andere auch […]

    Nur schöner 😉

    Aber ernsthaft. Auch, wenn selbst die meisten Mac-Nutzer es nicht wissen (und nicht verstehen würden, wass es bedeutet, wenn sie es wüssten): Max OS X, bzw. sein Unterbau Darwin, ist ein vollwertiges standardkonformes UNIX und unter X11 lässt sich jedes für UNIX geschriebene Programm kompilieren (bzw. jedes, bei dem ich das bisher ausprobiert habe). Python, Perl, et al. sind sowieso dabei, und R läuft nirgends mit mehr Stil als unter Mac OS X.

    Trotzdem stimme ich Jörg zu: Am Ende taugen nur Linux und andere freie UNIXe wirklich etwas, denn Apple könnte morgen entscheiden, diesen oder jenen Standard nicht länger zu unterstützen. Bei den freien UNIXen wird das nicht passieren.

  9. #9 Jörg
    03/30/2009

    Ja, OsX ist schon ein UNIX, wenn man die Wahl hat nur zwischen Windows und Mac ist das sicherlich die bessere Wahl und es lässt sich damit etwas anfangen.
    Aber bei meiner subjektiven Verachtung für das Apple-Gesamtkonzept ist das keine Option 🙂

    Mit den großen Datensätzen weiß ich nicht, Python setzt ja eigentlich auch nur auf C auf, aber für solche wirklichen Riesendatenberge muss man wahrscheinlich so Low Level wie möglich anfangen. Aber da würde sich doch anbieten, die kritischen Funktionen in C zu implementieren und mit Python zu wrappen. Wenn man sich mal Python angewöhnt hat, ist C wie Auto fahren mit zusammengebundenen Händen und Füßen…

  10. #10 Alex
    03/31/2009

    Python 2.6 ist jetzt Produktionsvariant. Ich empfehle, nichts später als 2.5.2 zu benutzen, da ich letzte Woche eine 2.4 Applikation verloren habe – zwölfstundige Ausfall, brauchte eine Weile um einige Anderungen im Time-modul aufzuspüren.