Das deutsche Python-Forum

Interessanter Blogeintrag über Django, Pylons und TurboGears:

http://jesusphreak.infogami.com/blog/vrp1

Leider in englisch, aber lesenswert!

Mit dabei sind auch einige nachdenkliche Punkte über django dabei...

Was sagt ihr zum Blogeintrag?



EDIT: Da wir schon mal dabei sind: http://wiki.rubyonrails.com/rails/pages ... erformance

Summary

Rails performed much better than Symfony. And Django performed much better than Rails.

Ich habe mir jetzt mal nur den Django-Teil durchgelesen, und werde also auch nur den kommentieren...

Was er über die Community und die Devs sagt stimmt aus meiner Sicht schon, wobei man sagen muss, dass es in den mailing-lists besser ist als im IRC.

Zu seinen 80%: Django ist ein Produkt einer Firma und war bzw ist an deren Bedürfnisse zugeschnitten. Stark erkennbar am Admin, wo es zum Beispiel keine Rowlevel-Permissions und hooks etc. gibt (noch nicht, newsforms wirds ja ändern ). Bei den Generic-Views fehlte mir bis jetzt noch nie etwas, es stimmt aber, dass man sie für extrem komplexe Sachen vielleicht nicht ganz so leicht verwenden kann!

Was er zu den Bugs sagt ist allerdings bedenklich, allerdings will Django ja einen Trac-Admin einstellen der fast nichts anderes tut als Tickets sortieren und zu ordnen, vielleicht wird es ja besser (Warten wir mal 1.0 ab, dürfte ja nicht mehr so lange dauern...)

Sein urls-Problem mit den Regexp ist teilweise verständlich, allerdings ist Django (bis auf die Templates) ja an Programmierer gerichtet und ich glaube jeder sollte Regexp halbwegs beherrschen. (Btw: Nicht die neuen Url-Funktions verwenden, die hauen bei mir vorne und hinten noch nicht ganz so hin Vielleicht liegts aber auch an mir, 1.0 wirds schon richten *gg*)

Zur Integration von anderen Komponenten (SQLAlchemy, Kid was weiß ich ) kommt mir vor will das Django-Team alles selbst machen, weil es ja extra auf ihre Anforderungen zugeschnitten ist und so einfache Änderungen schnell erlaubt...

Sein Vorschlag etwas außerhalb von Django wie Jinja zu verwenden ist lustig

Eine Application Datenbank wär was nützliches, nur sollte die gut durchdacht sein...

apollo13 hat geschrieben:Ich habe mir jetzt mal nur den Django-Teil durchgelesen, und werde also auch nur den kommentieren...

Ich habe alle gelesen und ich finde den Teil über TG auch sehr zutreffend und exakt der Grund warum ich TG nicht verwenden werde.

apollo13 hat geschrieben:Was er über die Community und die Devs sagt stimmt aus meiner Sicht schon, wobei man sagen muss, dass es in den mailing-lists besser ist als im IRC.

Wobei, ich habe adrian schon ab und zu mal im Channel gesehen.

apollo13 hat geschrieben:Bei den Generic-Views fehlte mir bis jetzt noch nie etwas, es stimmt aber, dass man sie für extrem komplexe Sachen vielleicht nicht ganz so leicht verwenden kann!

Das ist ja auch gar nicht ihre aufgabe. Wenn es komplex ist, ist es eben nicht mehr generisch. Dazu gibt es Custom VIews. Alles durch Generic VIews lösen zu wollen, scheint mir keine optimale Idee zu sein.

apollo13 hat geschrieben:Was er zu den Bugs sagt ist allerdings bedenklich, allerdings will Django ja einen Trac-Admin einstellen der fast nichts anderes tut als Tickets sortieren und zu ordnen, vielleicht wird es ja besser

Es gibt doch schon zwei oder drei? Aber die Erfahrung habe ich auch gemacht, von den Bugs in die ich reingelaufen bin, wurde bisher nur einer ausgebessert. Dafür war es aber der schlimmste.

apollo13 hat geschrieben:Sein urls-Problem mit den Regexp ist teilweise verständlich, allerdings ist Django (bis auf die Templates) ja an Programmierer gerichtet und ich glaube jeder sollte Regexp halbwegs beherrschen. (Btw: Nicht die neuen Url-Funktions verwenden, die hauen bei mir vorne und hinten noch nicht ganz so hin

Den URL-Mapper finde ich sogar recht gut gelungen. Und die URL-Funktionen habe ich bisher leider auch nicht richtig verstanden wie die gehen sollen. Oder sie lösen das Problem was ich habe einfach nicht, aber dann ist sie ziemlich wertlos.

Django ist für mich das Beste CRUD Framework momentan. Alles was darüber hinausgeht ist hat bei mir kein Framework ^^

Django: ein paar mal hab ich adrian schon im IRC gefunden, Bugs im Trac fixt man am Besten selber und macht Patches. Dann kommt das auch rein

Zu den Bugs: Kann es sein, das es einfach zu viele tickets gibt? z.Z. gibt es 732 offene Tickets: http://code.djangoproject.com/query Davon sind 319 als "accepted" markiert...
Der letzte als "accepted" Ticket hat die Nr. 3950... Aber es gibt zig tickets die eine wesendlich kleinere Nummer haben... Also noch einige sehr alte...

Wieviele Entwickler stecken hinter django? Wenn man sich die Timeline ansieht, scheint es nicht so viele zu geben, die wirklich code einpflegen, siehe: http://code.djangoproject.com/timeline? ... ate=Update

jens hat geschrieben:Zu den Bugs: Kann es sein, das es einfach zu viele tickets gibt? z.Z. gibt es 732 offene Tickets: http://code.djangoproject.com/query Davon sind 319 als "accepted" markiert...
Der letzte als "accepted" Ticket hat die Nr. 3950... Aber es gibt zig tickets die eine wesendlich kleinere Nummer haben... Also noch einige sehr alte...

Ja, das ist ein Problem, weil da noch einige zum Beispiel on pre-Magic-Removal sind und daher schon obsolet sind, d.h. entweder durch zufall gelöst oder einfach nicht mehr relevant.

jens hat geschrieben:Wieviele Entwickler stecken hinter django? Wenn man sich die Timeline ansieht, scheint es nicht so viele zu geben, die wirklich code einpflegen,

Commiter != Entwickler, dh. es gibt wesentlich mehr entwickler als Commiter, aber die kann man schlecht zählen. Commiter gibt es acht, davon haben sechs dieses Jahr schon Code commited (nicht unbedingt ihren Code, kann sein, dass sie einfach nur Patches integriert haben).

Leonidas hat geschrieben:

apollo13 hat geschrieben:Ich habe mir jetzt mal nur den Django-Teil durchgelesen, und werde also auch nur den kommentieren...

Ich habe alle gelesen und ich finde den Teil über TG auch sehr zutreffend und exakt der Grund warum ich TG nicht verwenden werde.

Scheint so als müsste ich die anderen auch lesen

Leonidas hat geschrieben:

apollo13 hat geschrieben:Was er über die Community und die Devs sagt stimmt aus meiner Sicht schon, wobei man sagen muss, dass es in den mailing-lists besser ist als im IRC.

Wobei, ich habe adrian schon ab und zu mal im Channel gesehen.

Stimmt schon, ich wollte auch nicht umbedingt verallgemeinern, aber sie sind doch recht selten im irc zu finden (adrian vielleicht ausgenommen). Soll jetzt aber keine Anschuldigung oder sonstwas sein, die haben halt auch noch andere Dinge zu tun als im IRC jeden Klacks zu beantworten...

Leonidas hat geschrieben:

apollo13 hat geschrieben:Bei den Generic-Views fehlte mir bis jetzt noch nie etwas, es stimmt aber, dass man sie für extrem komplexe Sachen vielleicht nicht ganz so leicht verwenden kann!

Das ist ja auch gar nicht ihre aufgabe. Wenn es komplex ist, ist es eben nicht mehr generisch. Dazu gibt es Custom VIews. Alles durch Generic VIews lösen zu wollen, scheint mir keine optimale Idee zu sein.

Hmm, okay das ist etwas falsch rübergekommen Aber sagen wirs mal so: object_list ist ja recht schon und man kann es gut verwenden, aber man kann auch komplexere Aufgaben damit lösen, indem man z.B einen Wrapper rundherum schreibt und hier hat man dann alle Freiheiten... Gedacht ist es natürlich nicht für alles, aber das hat er ja in seinem Blogeintrag eh selbst auch geschrieben

Leonidas hat geschrieben:

apollo13 hat geschrieben:Was er zu den Bugs sagt ist allerdings bedenklich, allerdings will Django ja einen Trac-Admin einstellen der fast nichts anderes tut als Tickets sortieren und zu ordnen, vielleicht wird es ja besser

Es gibt doch schon zwei oder drei? Aber die Erfahrung habe ich auch gemacht, von den Bugs in die ich reingelaufen bin, wurde bisher nur einer ausgebessert. Dafür war es aber der schlimmste.

Ja Jacob, Adrian und Malcom? Sie wollen aber einen der nichts anderes tut...
siehe groups:

=== Step 3: release ===

We'll need a release manager to make the final decisions about when/what to
release, which bugs are vital to be fixed, etc. This is about as far forward
as I've thought, though; I'm not sure who this should be, or exactly what
responsibilities s/he should have.

Leonidas hat geschrieben:

apollo13 hat geschrieben:Sein urls-Problem mit den Regexp ist teilweise verständlich, allerdings ist Django (bis auf die Templates) ja an Programmierer gerichtet und ich glaube jeder sollte Regexp halbwegs beherrschen. (Btw: Nicht die neuen Url-Funktions verwenden, die hauen bei mir vorne und hinten noch nicht ganz so hin

Den URL-Mapper finde ich sogar recht gut gelungen. Und die URL-Funktionen habe ich bisher leider auch nicht richtig verstanden wie die gehen sollen. Oder sie lösen das Problem was ich habe einfach nicht, aber dann ist sie ziemlich wertlos.

Ich finde sie auch gelungen und extrem gut, und habe kein Problem mit ihnen finde aber, dass seine Kritik eher lasch ist, denn das bisschen RegEx sollte jeder können.
Achja: Ich habe zur Zeit mit dem Url-tag und generic-views meine liebe Not, aber in 1.0 sollte das ja stable sein

Leonidas hat geschrieben:Commiter != Entwickler

Wie jetzt? Es gibt Entwickler die keinen SVN Zugriff haben? Oder zählst du all diejenigen dazu, die irgendwann mal einen Patch eingereicht haben???

Da es nur acht Leute gibt, die committen, wundert mich es allerdings nicht, das es Patches gibt, die es noch nicht ins SVN geschafft haben...

Bei http://www.djangoproject.com/documentat ... ehind-this stehen allerdings nur vier Leute...

apollo13 hat geschrieben:Stimmt schon, ich wollte auch nicht umbedingt verallgemeinern, aber sie sind doch recht selten im irc zu finden (adrian vielleicht ausgenommen). Soll jetzt aber keine Anschuldigung oder sonstwas sein, die haben halt auch noch andere Dinge zu tun als im IRC jeden Klacks zu beantworten...

Ja, ich verstehe schon deinen Punkt. Der Draht zu den Developern ist vielleicht nicht ganz so toll wie zu banbangert. Vom Support her ist #django sehr gut, aber um die Entwickler zu kontaktieren ist die Mailingliste besser. Malcolm antwortet netterweise auch noch freundlich auf Mails, aber mit dem Hinweis, dass man doch lieber in django-developers schrieben sollte.

apollo13 hat geschrieben:Ja Jacob, Adrian und Malcom? Sie wollen aber einen der nichts anderes tut...

Nein, ich meinte eigentlich Chris Beaven (SmileyChris), Simon Greenhill, Michael Radziej und Gary Wilson. Siehe hier. Wer Release Management macht weiß ich nicht, das könnte James Bennett oder Russ sein, aber da müsste ich erstmal im IRC nachfragen.

Leonidas hat geschrieben:

apollo13 hat geschrieben:Ja Jacob, Adrian und Malcom? Sie wollen aber einen der nichts anderes tut...

Nein, ich meinte eigentlich Chris Beaven (SmileyChris), Simon Greenhill, Michael Radziej und Gary Wilson. Siehe hier. Wer Release Management macht weiß ich nicht, das könnte James Bennett oder Russ sein, aber da müsste ich erstmal im IRC nachfragen.

Okay ich meinte dann wohl eher die Mainentwickler

Leonidas hat geschrieben:Wer Release Management macht weiß ich nicht, das könnte James Bennett oder Russ sein, aber da müsste ich erstmal im IRC nachfragen.

Ist Bennett.

Was mir noch zum Thema django und externe OpenSource Entwickler einfällt: Ich meine ich hätte irgendwo gelesen, das es in django keine copyright Hinweise in den Quellen vorkommen sollen.
Irgendwie ist das auch nicht so ganz OpenSource like, oder?

jens hat geschrieben:Irgendwie ist das auch nicht so ganz OpenSource like, oder?

Wieso nicht?

Eine LICENSE oder COPYING im Root des Sourcecodes reicht mMn auch aus.

Geschmackssache...

birkenfeld hat geschrieben:Eine LICENSE oder COPYING im Root des Sourcecodes reicht mMn auch aus.

Außerdem gibt es ja eine AUTHORS-Datei.

jens hat geschrieben:Da es nur acht Leute gibt, die committen, wundert mich es allerdings nicht, das es Patches gibt, die es noch nicht ins SVN geschafft haben...

Um es noch mal aufzufrischen. Ich denke schon, das django, als Projekt, da ein Problem hat... z.Z. warten 45 Patches darauf eingecheckt zu werden: http://code.djangoproject.com/query?sta ... or+checkin

Das ist eine ganze Menge. Und all diese Tickets sind eigentlich fertig zum einchecken, zumindest ist stage="Ready for checkin" markiert worden.

In der devel-Mailingliste gibt's auch wieder eine kleine Diskussion darüber: http://groups.google.de/group/django-de ... 606385479e

Dadurch das django so populär ist, gibt es viel was die Community will und sie bieten auch die Hilfe an. Zumindest werden viele Patches eingereicht. Aber die Projekt-Leader kommen einfach nicht nach. Ist auch irgendwie verständlich.

Auf der anderen Seite ist es auch wieder gut, das nicht jeder Patch voreilig eingebunden wird. So bleibt der SVN trunk stabiler...

Sowas kann auch irgendwann zum guten Grund werden, Django nicht zu benutzen.

Dumm ist wenn django-Apps voraussetzten, das man Patches eingespielt hat, damit alles funktioniert. z.B. stockphoto:

+ recommended: Patch your Django installation against `ticket 1484`_
...
+ Without the Django patch listed above, the batch import feature is only
likely to work for very small archives.

(aus der README)

Y0Gi hat geschrieben:Sowas kann auch irgendwann zum guten Grund werden, Django nicht zu benutzen.

Es steht einem auch jederzeit frei Django zu forken. Nur sollte man es dann auch selbst besser machen können, was andererseits auch gar nicht so einfach ist.

Dann den eigenen Fork parallel nachzupatchen ist auch nicht besser. Wünschenswert ist einfach, dass die Patches in Django zeitnah eingepflegt werden. Wenn dazu keine externe Hilfe (z.B. freiwillige Entwickler) in Anspruch genommen und intern nichts dafür getan wird (ich kenne die Hierachie bei Django nicht, sofern es eine gibt, ebenso wenig weiß ich, welche Rolle die Firma spielt, die meines Wissens Django ursprünglich entwickelt hat), dann liegt für mich die Schuld beim Django-Team. Wenn man sich dort nicht helfen lassen will, kann man sich besser ein anderes Framework suchen, das aktiv(er) gepflegt und weiter entwickelt wird. Problematisch wird es in dem Moment, wo es nichts vergleichbares gibt. Selbst diese Aufgabe zu übernehmen bedeutet aber das Rad irgendwo neu zu erfinden, anstatt sich vollkommen auf die eigentlichen Ziele des eigenen Projekts (z.B. einer Anwendung) konzentrieren zu können.