Optimierungsbedarf Code von BMaxzu Python

[noise]

Oder die Original-Docs in verständlicher, denn wie sonst komme ich jemals auf die itertools oder jetzt die defaultdict, die es auch erst ab 2.5 gibt?

Huch?

1. http://docs.python.org/
2. http://docs.python.org/whatsnew/whatsnew25.html
3. http://docs.python.org/lib/lib.html

Ich finde, mit Abstand, das Python eines der vollständigsten und umfangreichsten Dokumentionen hat. Natürlich kommt es schon mal vor das etwas nicht ganz korrekt ist, aber man kann sich doch direkt an die Zuständigen wenden.

( bevor ich mir D anschaue, lerne ich lieber noch was C, das kann ich wenigstens hier anwenden, obwohl auf den ersten Blick kommt mir D einleuchtender vor als dein Python-Code , halt eher bekanntes Terrain...)

Ich finde D ist das C/C++ das ich mir immer gewünscht habe. Aber die frage ist auch mehr eine Ideologische:
1. Schwimme ich mit dem Mainstream (C++/Java/$INSERT_HERE_YOUR_LANGUAGE) oder entscheide ich mich für eine Sprache die nicht so populär ist aber meinem Denken mehr entspricht.
2. Muss/will ich damit Geld verdienen oder nicht.

Ich für mein Teil finde D sehr schön und mäße dem ein größeren Wert bei als z.B. C++ und Java. Obwohl ich reines C auch sehr schön finde und sehr Performant. Aber ich will ja auch nicht mit Programmieren mein Geld verdienen. Wenn dem so wäre würde ich C++ und/oder Java Programmierer sein, da die Chancen besser aussehen eine Anstellungen zu finden, statt mit Python. Die Chancen mit D eine Anstellungen zu finde sind gleich null, da die Sprache sehr Jung ist und die IT-Welt nocht nicht wirklich was von mitgekriegt hat.

[Yogi]

@Leonidas: Du hast mich da missverstanden. Das sollte nicht als gemeckere rüber kommen. Es ist halt nur so, dass Python eine andere Philosophie hat, wie die Sprachen die ich kenne. Und dafür sind die Docs MIR manches male zu unübersichtlich. Vielleicht bräuchte ich sowas wie: von Java nach Python oder so ähnlich. Mein gepackt Buch finde ich z.B sehr nett, leider isses die 2.Auflage mit Python 2.4. Das in der 2.5 die OOP-Funktionalität erweitert worden ist, war mir nicht bewusst, mein Fehler. Jetzt habe ich mir die 3. Auflage geholt und bin sehr zufrieden. Sogar die wichtigen Properties werden da erklärt. Von da aus, komme ich wahrscheinlich besser mit den Original-Docs klar. Muss halt erst einmal alles sickern...

@noise: siehe oben, definitiv kein Gemecker, ehrlich
Ich lerne jetzt noch C dazu und bin überrascht wie gut ich damit zurecht komme. Endlich mal dieses ganze Zeigergedöns verstehen. Aber bevor ich mir C++ nochmal tiefer gehend anschaue, werde ich mich lieber noch mehr in Java vertiefen. Aber momentan reicht mir und brauche ich auch nicht mehr als Python, C und BlitzMax und ein bisschen Java.

Ich bin ehrlich sehr begeistert von Python und den ganzen schönen netten Modulen.

[Leonidas]

Und dafür sind die Docs MIR manches male zu unübersichtlich. Vielleicht bräuchte ich sowas wie: von Java nach Python oder so ähnlich. Mein gepackt Buch finde ich z.B sehr nett, leider isses die 2.Auflage mit Python 2.4. Das in der 2.5 die OOP-Funktionalität erweitert worden ist, war mir nicht bewusst, mein Fehler. Jetzt habe ich mir die 3. Auflage geholt und bin sehr zufrieden. Sogar die wichtigen Properties werden da erklärt. Von da aus, komme ich wahrscheinlich besser mit den Original-Docs klar. Muss halt erst einmal alles sickern...

Also es gibt schon Dokumente wie "What's new in Python X.Y", sind meiner Meinung nach durchaus lesenswert.
Und, ähm, wo in 2.5 OOP erweitert worden ist, ist mir nicht so ganz klar. Wenn du Deskriptoren meinst, die sind mindestens seit 2.2.3 dabei.
Und Python is not Java ist sicherlich für dich nützlich. Du darfst eben nicht erwarten, alles in der offiziellen Doku zu finden, denn dann würde sie absolut endlos sein ("CPython-Module in OCaml kompilieren", möglich, aber nicht in der offiziellen Dokumentation nötig).

[Yogi]

Ich kann dir genau sagen was für mich neu ist, da nicht in Michael Weigends Python Ge-Packt Buch 2. Aufl.. Statische Methoden und die Properties z.B fehlten komplett.

Wobei mir jetzt was witziges aufgefallen ist. In meiner 3. Ausgabe werden statische Methoden anders definiert als in dem Online-Index bei Amazon und wie in der Python Doc. Und zwar definieren letztere statische Methoden mit @staticmethod vor der Methode und in seinem Buch werden die einfach nur mit staticmethod(Methodenname) aufgerufen

Kann ja sein, dass das alles schon vorher drinne war, aber wenn ich als Neueinsteiger einen Titel vorliegen habe, der sich 'praktische Referenz' nennt, dann gehe ich erst einmal davon aus, dass alles wesentliche enthalten ist. Wenn er jetzt plötzlich in der 3.Auflage neues einbringt, dann gehe ich erst einmal davon aus, dass sie neu sind und nicht nur vergessen worden sind.

Aber trotzdem danke für den hilfreichen Link wegen Java und Python.

[noise]

Und zwar definieren letztere statische Methoden mit @staticmethod vor der Methode und in seinem Buch werden die einfach nur mit staticmethod(Methodenname) aufgerufen

http://www.python.org/dev/peps/pep-0318/
http://www.python.org/doc/2.4/whatsnew/whatsnew24.html
http://wiki.python.org/moin/FrontPage?a ... arch=Titel

Da ich kein Java-Programmierer bin und daher nicht weiß ob es in Java First-Class-Functions und closures gibt (darauf basiert halt das ganze), schreibe ich das folgende.

mit ``@`` Dekoriert man Funktionen und Methoden. Dieses Future wurde in Python 2.4 eingeführt, weil, IMHO, die Python Programmierer angefangen haben immer mehr Funktionen zu schreiben die als Decorator eingesetzt wurden.

Dekoratoren werden definiert, in dem der äußeren Funktion eine inner definiert wird, die beim aufruft der äußeren zurückgegeben wird. Stichwort closures

Code: Alles auswählen

def mydeco(f):
    def inner(*args, **kwargs):
        print "args: %r; kwargs: %r" % (args, kwargs)
        return f(*args, **kwargs)
    return inner

@mydeco
def my_func1(a, b=2):
    return a * b

print my_func1(2)

Dabei ist

Code: Alles auswählen

@mydeco
def my_func1(a, b=2):
    return a * b

äquivalent mit

Code: Alles auswählen

def my_func1(a, b=2):
    return a * b
my_func1 = mydeco(my_func1)

``@`` ist also nur syntaktischer Zucker, um das Dekorieren näher an die Funktionsdefinition zu "Binden".


So, dann gibt es noch folgenden Form, die es zulässt dem Decorator Argumente zu übergeben:

Code: Alles auswählen

def mydeco(counts):
    assert not hasattr(counts, "__call__")

    def inner(f):
        def inner_inner(*args, **kwargs):
            print "args: %r; kwargs: %r, counts: %r" % (args, kwargs, counts)
            return f(*args, **kwargs)
        return inner_inner
    return inner

@mydeco(100)
def my_func1(a, b=2):
    return a * b

print my_func1(2, b=3)

Dies ist äquivalent mit der hässlichen Variante

Code: Alles auswählen

def my_func1(a, b=2):
    return a * b
my_func1 = mydeco(100)(my_func1)

Dann gibt es noch Deskriptoren (``property`` und ``classmethod`` sind sogenannte Deskriptoren), die man dann auch als Decorator benutzen kann.

Zum Thema descriptors:
http://docs.python.org/ref/descriptors.html
http://www.python.org/doc/2.2.3/whatsne ... 0000000000
http://users.rcn.com/python/download/Descriptor.htm
http://gulopine.gamemusic.org/2007/nov/ ... rt-1-of-2/

Kann ja sein, dass das alles schon vorher drinne war, aber wenn ich als Neueinsteiger einen Titel vorliegen habe, der sich 'praktische Referenz' nennt, dann gehe ich erst einmal davon aus, dass alles wesentliche enthalten ist.

Darauf kannst du dich aber nicht verlassen. Bücher veralten schneller als man denkt und die Online-Dokumentation ist immer up2date.

EDIT:
Klassen kann man momentan nicht mit ``@`` dekorieren (Da muss man ahlt mit der gewöhnlichen Syntax leben). Class-Decorators mit ``@`` wird es aber in Py3K geben, worauf ich mich schon richtig freue

[Leonidas]

Da ich kein Java-Programmierer bin und daher nicht weiß ob es in Java First-Class-Functions und closures gibt

Wenn ich mich richtig erinnere: Nein (Higher order functions) und Nein (Closures), da es keine Nested Functions gibt. Vielleicht kann man mit Nested Classes so etwas ähnliches bauen...

Interessanterweise kann GCCs Gnu89-C-Dialekt Nested Functions

[BlackJack]

Wobei der `gcc` da soweit ich weiss auch nur verschachtelte Funktionen kann und keine Closures. Wenn der äussere Funktionsaufruf beendet ist, sind auch alle lokalen Variablen weg, weil die auf dem Stack liegen.

[Leonidas]

Ja, stimmt:

If you try to call the nested function through its address after the containing function has exited, all hell will break loose.

[Yogi]

Hilfe!! Ich habe das Gefühl, dass immer wenn ich glaube was verstanden zu haben, sich ein neuer Abgrund auf tut...
Python ist ja so dermaßen in der stetigen, weiteren Entwicklung, dass ich als Python-Newbie gar nicht weiß wo ich da einsteigen soll. Zu jedem Thema gibt es ellenlange tiefer greifende Dokumentationen. Da komme ich langsam vor lauter lesen nicht mehr zum programmieren

Am besten ich fange einfach an und halte alles refaktorierfähig

PS: Mit den closures habe ich noch so meine Schwierigkeiten. Auch hatte ich mich daran gewöhnt alles in Klassen und Objekten zu sehen, aber in Python ist das scheinbar gar nicht immer so erwünscht, oder??

[BlackJack]

Als Objekte solltest Du schon alles sehen (können). Alles in Python ist Objekt, inklusive Funktionen. Man muss halt nur nicht unbedingt zu jedem Objekt eine Klasse sehen, es gibt ja auch Funktionsdefinitionen um Funktionsobjekte zu erstellen. Und die können dann auch Closures sein.

[Leonidas]

PS: Mit den closures habe ich noch so meine Schwierigkeiten.

In der Regel brauchst du Closures nicht. Wenn du Closures brauchst, dann wirst du das selbst feststellen.

[noise]

@Yogi: Nur weil Python viele Möglichkeiten der Meta-Programierung bietet, heißt das ja nicht das man die auch alle braucht/nutzen muss

- Metaklassen. Eine sehr nette Sache für die es aber kaum Einsatzgebiete gibt. Ich behaupte auch zu sagen das man 70% der Fälle wo meine eine Metaklasse schreibt, genauso einen Klasendekorator benutzen kann paradebeispiel das: [wiki]Metaklassen[/wiki] Registrieren von Instanzobjekten (Schön für ein Plugin-System). Aber, das ganze kriegt man auch mit nem Klassendekorator hin und das **ohne** Probleme mit der MRO[1] zu kriegen
- Descriptors. Sehr schöne Sache (Bin Fan von), aber man braucht sie weniger als man denkt.

- Closures. Siehe Post von Leonidas. Dagegen brauche ich öfter mal Funktionen innerhalb einer Funktion die ich nur dort brauche und nicht als closure.

- Mit Py3K kommen noch ABC und Function-Annotations hinzu, von denen ich ABC nutzen werde.

Von daher macht dich nicht zu sehr verrückt und beschäftige dich nach und nach mit dem. Vieles davon braucht man ehe nur selten.


[1]: Ihr wisst ja, man kann einer Klasse keine zwei Metaklassen zuweisen (was ja auch Logisch ist!). Einer der Gründe weshalb ich Metaklassen auch nicht mag und extrem selten einsetze.

EDIT: *argh* MRO und nicht ORM!