Das deutsche Python-Forum

(jelöscht)

Ich hab nur mal angefangen das ganze zu überfliegen, da ich eigentlich beim Weg aus der Tür raus bin, aber:

• easy_install django -- der offizielle Paketname ist Django, bitte auch diesen verwenden, selbst wenn easy_install auch django kapiert.
• Weiters würde ich easy_install durch pip ersetzen, easy_install verwendet heute selten einer…
• Wir öffnen also ein Terminal mit Administratorrechten und setzen den Befehl easy_install django ab. -- Es gibt keinen einzigen Grund hier Administratorrechte zu verwenden.
• Bei der Closure section stimmen die Einrückungen nicht, außerdem willst du dir bitte pep008 zu Gemüte führen.
• Die Pythoneinführung hab ich übersprungen, das sollen andere beurteilen die didaktisch vlt besser drauf sind als ich.
• "Eine Anwendung ist wieder ein Ordner." -- Ähm nein, Django ist in Python geschrieben und deshalb solltest du von Modules und Packages reden, eine Anwedung muss kein Ordner sein (wenn ich es noch richtig im Kopf habe muss eine Anwendung irgendwas sein was nen models sub module hat, das ändert sich vlt bis 1.5 noch)
• "Eine View ist eine einfache Funktion" -- Ein view ist alles was callable ist, ob Funktion oder Objekt ist hier egal
• "Es gibt Module für FastCGI, Apache (mod_wsgi) und viele andere Möglichkeiten. In der Regel nutzt man nur die ersten beiden" -- Unglücklich formuliert, sehr viele Deployments verwenden auch Nginx, FastCGI verwendet hoffentlich keiner mehr
• "'NAME': 'djangotut/db.sqlite3'" -- relative Pfade sind ein schlechtes Beispiel, spätestens wenn die Leute das dann auf ihren Webserver packen jammern sie in #django warum Django die Datenbank nimmer findet
• "Durch die Verwendung des ORMs wird übrigens auch eine extrem häufig auftretende Sicherheitslücke vollständig eleminiert: Die gefürchtete SQL-Injection.": Das stimmt nur solange man das ORM richtig verwendet (eg .raw und .extra erlauben durchaus SQL-injections wenn der Benutzer nicht weiß was er tut)
• post = Entry.objects.get(pk=post_id) -- post_id ist dort ein String, besser ist explizit int(post_id)
• url(r"post/(\d+)/$", "show_post"), -- dort fehlt ein ^ für match auf den beginn des strings.
• return render_to_response("post.html", {"post": post}, RequestContext(request)) -- https://docs.djangoproject.com/en/dev/t ... ts/#render render inkludiert den RequestContext schon
• url(r'^blog', include('blog.urls')), -- slash am Ende fehlt

Weiter bin ich auf die schnelle noch nicht gekommen

EDIT:// Ich habe nächste Woche möglicherweise nicht sehr viel Internetzugang, also nicht wundern wenn ich auf deine Antwort nicht anworte

Hallo.

Vor über einem Jahrzehnt hat man sich jedoch darauf geeinigt vier Leerzeichen zum Einrücken zu verwenden.
Ich für meinen Teil finde es jedoch schwachsinnig mit Leerzeichen einzurücken und nehme deswegen Tabs, weil da jeder selbst entscheiden kann, wie breit die Einrückungen wirklich sind.

Sich in einem Tutorial gegen einen etablierten Standard zu stellen ist schon ein wenig eigenartig. Diesen dann nebenher als "schwachsinnig" zu bezeichnen bedarf wohl keinem Kommentar. Eine Äußerung in dieser Art gehört in keinen vernünftigen Text.

Der Hinweis auf PEP 8 wurde ja schon gebracht. Für mich ist das Einhalten der Konventionen einer Sprache meist schon ein guter Indikator für das Verständnis der Sprache. Bei idomatischem Code kann man davon ausgehen, dass der Autor weiß, was er dort tut und die grundlegensten Eigenschaften der Sprache verstanden hat.

Vielleicht ein wenig spitzfindig: ich würde nicht von der Funktion "Closure()" schreiben, sondern von der Funktion "Closure". Die Klammern gehören nicht mit zum Funktionsnamen.

Wenn ich Konstruktionen wie ``if var == True`` sehe, dann läuten bei mir eigentlich einige Alarmglocken. Ich will an einem so kleinen Stück Code nicht zu viel aufhängen und dir sicher nicht die Fähigeit absprachen, halbwegs vernünftige Programme zu schreiben, aber ob die Qualität für ein Tutorial ausreichend ist würde ich zumindest mal anzweifeln.

Mich wundert auch ein wenig, warum du keine richtigen Beispiele verwenest. Bei den Generatoren ist es ja ganz gut gelungen, bei den Closures und den Dekoratoren ist es aber mehr oder weniger unübersichtlich. Ich würde mich eher an etwas halten, was dem Leser eingänglich ist und nicht irgend etwas abstraktes. Auch verstehe ich nicht, warum du um das Beenden des Generators so ein Ding machst. Hier gehst du ins Detail, obwohl das eigentlich nicht nötigt ist.

An deiner Stelle würde ich das Tutorial über Python ganz rauslassen, mit so einer kurzen Einführung, welche auch noch beliebige Teile der Sprache behandelt, kannst du eigentlich nur einen Griff inst Klo landen Versteh das nicht falsch, aber die Einführung ist für eine sinnvolle Darstellung zu ungenau, an anderen Stellen im Netz findet man einfach schon fertige und bessere Tutorials. Ich würde einfach darauf verweisen.

Die restlichen Kapitel habe ich mir nicht angeschaut, dazu fehlen mir zum Teil das Interesse und ein ordentlichen Stück an Zeit.

Sebastian

EyDu hat geschrieben:Sich in einem Tutorial gegen einen etablierten Standard zu stellen ist schon ein wenig eigenartig. Diesen dann nebenher als "schwachsinnig" zu bezeichnen bedarf wohl keinem Kommentar. Eine Äußerung in dieser Art gehört in keinen vernünftigen Text.

+1, hatte das in meiner Liste auch drin, ist aber wohl irgendwo entschwunden.

An deiner Stelle würde ich das Tutorial über Python ganz rauslassen, mit so einer kurzen Einführung, welche auch noch beliebige Teile der Sprache behandelt, kannst du eigentlich nur einen Griff inst Klo landen Versteh das nicht falsch, aber die Einführung ist für eine sinnvolle Darstellung zu ungenau, an anderen Stellen im Netz findet man einfach schon fertige und bessere Tutorials. Ich würde einfach darauf verweisen.

Auch +1, ich würde sogar noch weiter gehen und sagen, dass jemand der absolut keine Ahnung von Python hat die Finger von Django lassen soll (oder zumindest sehr viel Eigeninteresse mitbringen sollte und nicht wegen jedem falschen Tag oder Beistrich in tuples in #django nachfragen soll -_-)

(jelöscht)

enkore hat geschrieben:"*Ich* für *meinen Teil* *finde* ..." ist so eindeutig eigene, nicht-normative Meinung, dass ich das so nicht gelten lasse. Im Tutorial halte ich mich auch an PEP 8, manchmal kommen noch Tabs vor, aber das ist ein Fehler und keine Absicht

Ich hatte auch kein Problem mit deiner Meinung, ich hatte ein Problem mit dem Begriff "schwachsinning". Da kannst du vorher noch so gute Argumente bringen, die Ausdruck reißt es dann ins Unsachliche.

EyDu hat geschrieben:Vielleicht ein wenig spitzfindig: ich würde nicht von der Funktion "Closure()" schreiben, sondern von der Funktion "Closure". Die Klammern gehören nicht mit zum Funktionsnamen.

Die Klammern gehören nicht zum Funktionsnamen, korrekt. Diese Konvention habe ich mir bei einigen Fachbüchern abgeschaut um den Leser besser zwischen Funktionen und Objekten unterscheiden zu lassen.

enkore hat geschrieben:Ist ne blöde Angewohnheit; manchmal schreibe ich noch die Wahrheitskonstante dahinter, kommt vom Arbeiten mit C/C++ und Libs, die da komischen Kram definieren.

Ehrlich gesagt kann ich mir kaum vorstellen, dass das irgendwo notwenig sein sollte. Mal abgesehen davon, dass der Wert eines enums als Ergebnis eines Funktionsaufrufs geliefert wird, welcher explizit getestet werden muss. Ich arbeite mittlerweile Seit mehr als drei Jahren jeden Tag mit C++, mis ist bisher noch keine einzige Bibliothek untergekommen, in der ein Test auf Wahrheitswerte notwenig gewesen ist. Aber wie gesagt, ich will nichts an einer Zeile Code aufhängen, jeder baut sich mal irgendwo einen ärgerlichen Schnitzer ein, über den er sich dann ärgert.

enkore hat geschrieben:Kann ich machen, allerdings finde ich es sehr sinnvoll kurz zu erklären, was Dekoratoren, Closures und Generatoren sind, weil nicht jeder die kennt oder die Funktionsweise ganz durchschaut, aber sie wichtige Konzepte sind.

Ok, wenn du nur grundlegende Kenntnisse in Python voraussetzt, dann kann man das durchaus so machen. Ich würde es dann allerdings dort einbringen, wo es benötigt wird. So arbeitet man auch gleich an einem konkreten Beispiel und der Leser kann sich etwas darunter vorstellen. Etwas am Anfang zu erkären, was dann erst in den späteren Kapiteln irgendwo genutz wird, finde ich etwas ungeschickt. Wahrscheinlich wird man dann die Einführung an entsprechender Stelle nur noch einmal lesen müssen.
Das ist aber wohl eher eine Frage des persönlichen Geschmacks und der Erwartungshaltung an den Leser. Da möchte ich auch nicht versuchen dir ins Konzept zu reden. Ist ja nicht mein Werk, sondern deins.

(jelöscht)

enkore hat geschrieben:@3: IDR ist das (Standard-)Installationsverzeichnis nicht von normalen Nutzern beschreibbar.

Das ist auch gut so, denn IDR sollte man dort auch nichts hinschreiben, es gibt --user für eine Installation nach ~/.local oder man verwendet ein virtualenv (was alles in allem die beste Idee ist)

@2: Halte ich für nich so relevant, kann ich ändern

Relevant oder nicht, ein Tutorial sollte imo aktuelle best practices erklären.

@8: Eh ich glaube du verwechselst FastCGI und CGI. Jeder, der z.B. nginx nutzt, nutzt FastCGI als Schnittstelle zwischen Appserver und Webserver.

FastCGI ist nur eine Option für Nginx, die aber keiner verwendet. Grundsätzlich will man von https://docs.djangoproject.com/en/1.4/howto/deployment/ nur die erste Option verwenden und FastCGI/SCGI/AJP komplett vergessen.

Die drei Punkte zeigen eigentlich auch, dass du dich etwas mehr mit den aktuellen best-practices auseinander setzen solltest, denn wenn je,and in #django fragt warum seine FastCGI Anbindung nicht geht bin ich der erste der ihn fragt wer ihm den Blödsinn angeraten hat

@apollo13: Was benutzt man denn dann für nginx als „best practice”? Die verlinkte Django-Doku sagt da irgendwie nichts zu. Und wenn man im Netz sucht findet man Anbindungen per FastCGI und diverse Proxy-Lösungen mit nginx diversen WSGI-Servern. Ich hatte nicht den Eindruck das explizit von FastCGI abgeraten oder eine der anderen Lösungen als *die* Lösung hervor sticht.

(jelöscht)

Nach meinem fastcgi: prefork oder threaded? - minspare, maxspare usw... Thread nutzte ich auch kein fastCGI mehr, sondern nginx und Gunicorn...

Mittlerweile habe ich ein paar Varianten durch: http://www.pylucid.org/permalink/401/ho ... -webserver

Wäre natürlich toll, wenn es einen klaren Favorit gibt.

btw. man muß auch mal an http://wiki.python.de/Python%20Webspace ran. Es gibt fast keine Angebote die "mehr" als fastCGI bieten.

(jelöscht)

BlackJack hat geschrieben:@apollo13: Was benutzt man denn dann für nginx als „best practice”? Die verlinkte Django-Doku sagt da irgendwie nichts zu. Und wenn man im Netz sucht findet man Anbindungen per FastCGI und diverse Proxy-Lösungen mit nginx diversen WSGI-Servern. Ich hatte nicht den Eindruck das explizit von FastCGI abgeraten oder eine der anderen Lösungen als *die* Lösung hervor sticht.

Imo tunnel auf Gunicorn oder UWSGI (Bzw das ist das was ich mitbekomme dass die Leute verwenden). FastCGI mit flup verursacht erfahrungsgemäß die meisten Probleme und darum rate ich davon ab. Wer FastCGI verwenden will kann es natürlich gerne tun, aber ich würde es in einem Tutorial nicht erwähnen (bzw erst hinter den moderneren Optionen).

enkore hat geschrieben:Nach meinem gegenwärtigen Kenntnissstand wären das FastCGI via flup und WSGI (via uwsgi, gunicorn oder mod_wsgi) in Verbindung mit nginx oder Apache 2.

auch FastCGI via flup ist WSGI

enkore hat geschrieben:Sehe ich ähnlich, in Debian Stable ist eh noch nginx 0.7.x drin, den man selber kompilieren müsste, um uwsgi-Support zu bekommen.

Was ziemlich egal ist, die meisten großen Deployments müssen so oder so irgendwas händisch kompilieren, ist zwar suboptimal geht aber oft nicht anders. (Klar, für nen Tutorial ist das blöd, aber wer Debian stable verwendet kann dann ruhig auch apache + mod_wsgi verwenden )

Mit FCGI habe weder ich noch sehr viele andere Leute je Probleme gehabt, es ist schnell und einfach und überall verfügbar. Natürlich gehe ich im Deployment-Kapitel auch auf die moderneren Techniken ein, aber für viele Anwendungen wird der Appserver per FCGI angebunden werden...

Hmm, als langjähriger Supporter im #django Channel würde ich nicht behaupten, dass FastCGI einfach ist, ymmv. Klar wenns rennt rennts nicht so schlecht, aber bis es mal rennt ists nen PITA (ich sag nur FORCE_SCRIPT_NAME und Freunde…)