django Alternative: web2py ?

[jens]

Wurde gerade auf web2py aufmerksam gemacht:
http://mdp.cti.depaul.edu/
http://en.wikipedia.org/wiki/Web2py

Hatte ich bisher noch nie was von gehört. Wer kann was darüber sagen?

[derdon]

http://www.python-forum.de/topic-17057.html und http://www.python-forum.de/topic-13752.html gelesen?

[jens]

Danke für die Links, sehr lesenswert.
Offensichtlich ist web2py auch eine one-man-show. Zumindest sind alle commits von der selben Person, siehe: http://code.google.com/p/web2py/source/list

Fazit: Nicht brauchbar...

Hätte auch selbst mal drauf kommen können zu suchen

EDIT: Btw. Hab mal web2py hier hinzugefügt: [wiki]Web-Frameworks#Webpy[/wiki]
Sollte man ja zumindest erwähnen

[Leonidas]

Offensichtlich ist web2py auch eine one-man-show.

Das muss ja per-se nichts schlechtes sein, Werkzeug hat ja auch nicht so viele Entwickler. Das Problem ist aber dass der Entwickler von vielen Dingen schlicht keine Ahnung hat und versucht seinen Kram zu verkaufen. Mir tun die Leute leid die drauf reinfallen und später auf die Nase fallen.

Btw. Hab mal web2py hier hinzugefügt: [wiki]Web-Frameworks#Webpy[/wiki]
Sollte man ja zumindest erwähnen

Wozu? Persönlich halte ich jede unnötige Erwähnung von web2py für einen Fehler

Andererseits muss ich ja zugeben, dass die Wiki-Seite ja dermaßen outdated ist, dass es nicht mehr lustig ist. Vor allem der TurboGears-Part, der war wohl zuletzt in Version 0.7 aktuell. Ich glaube in der Kölner Usergroup waren paar Leute die TG genutzt haben - wäre klasse wenn da jemand mit mehr aktuellem Einblick den Abschnitt zu TG aktualisiert.

Lunar, könntest du vielleicht ein paar Punkte zu Pylons hinzufügen? Ich denke man sollte Pylons inzwischen über TurboGears schreiben, wenn TG sowieso dorthin migriert ist es sinnvoll das zuerst zu nennen. Ich für meinen Teil habe den Django-Teil schon etwas ausgebessert.

[jens]

Das muss ja per-se nichts schlechtes sein, Werkzeug hat ja auch nicht so viele Entwickler.

Klar, Werkzeug ist aber auch um Größenordnungen kleiner... Noch krasser wird es, wenn man bedenkt wie viele z.B. an django Arbeiten (Hauptentwickler + die ganzen "externen" Helfer).
Ich würde sagen, auch der beste Programmierer, der die beste "Ahnung" hat wird es nicht schaffen ein zweites django auf zu ziehen. Ganz einfach weil die manpower nicht reichen wird.

[Leonidas]

Klar, Werkzeug ist aber auch um Größenordnungen kleiner... Noch krasser wird es, wenn man bedenkt wie viele z.B. an django Arbeiten (Hauptentwickler + die ganzen "externen" Helfer).

Klar, wenn mitsuhiko jetzt auch versuchen würde Werkzeug mit einem selbstgemachten ORM zu verheiraten und obendrauf noch ein eigenes Admin-Interface machen würde, tät ich mir auch erstmal auf die Stirn klopfen. Ein ORM ist eben nichttrivial, eine Templatesprache wie Jinja ist ja wesentlich einfacher zu machen.

[lunar]

Lunar, könntest du vielleicht ein paar Punkte zu Pylons hinzufügen? Ich denke man sollte Pylons inzwischen über TurboGears schreiben, wenn TG sowieso dorthin migriert ist es sinnvoll das zuerst zu nennen. Ich für meinen Teil habe den Django-Teil schon etwas ausgebessert.

Und was soll ich da jetzt schreiben bzw. welche Kriterien soll ich für eine wie auch immer geartete Beurteilung von Pylons anwenden? Pylons selbst ist doch nichts außer ein bisschen Convention um Paste herum in Verbindung mit einer (unverbindlichen) Auswahl an Bibliotheken und einem sehr hübschen Webdebugger. Pylons selbst hat keine Template-Engine, kein ORM, kein Authentifizierungsmodul und keine Formbibliothek. Man nimmt halt, was Pylons empfiehlt, und wenn man es nicht mag ... nun, der Cheeseshop ist groß.

Mako nutze ich nicht, weil ich mit Django und Jinja angefangen habe und nicht umlernen möchte. FormEncode ist mir zu kompliziert, daher tut eben wtforms. Pylons nutze ich immer noch, nur eben nicht mit den Komponenten, die es mir empfiehlt.

Ganz abgesehen davon, dass ich diese Wikiseite in ihrer jetzigen Form eh für völlig unsinnig halte. Entweder man beschreibt jedes Framework kurz und knappt und verlinkt dann auf die Website oder man einigt sich auf vernünftige Vergleichskriterien, damit der Vergleich dann auch aussagekräftig ist. So aber ist die Seite weder eine gute Übersicht (wenn interessiert denn der Preis von Ellington CMS?) noch ein guter Vergleich ("kann auch als Vorteil gesehen werden" ist in einem vernünftigen Vergleich keine sinnvolle Aussage).

[Leonidas]

Und was soll ich da jetzt schreiben bzw. welche Kriterien soll ich für eine wie auch immer geartete Beurteilung von Pylons anwenden? Pylons selbst ist doch nichts außer ein bisschen Convention um Paste herum in Verbindung mit einer (unverbindlichen) Auswahl an Bibliotheken und einem sehr hübschen Webdebugger. Pylons selbst hat keine Template-Engine, kein ORM, kein Authentifizierungsmodul und keine Formbibliothek. Man nimmt halt, was Pylons empfiehlt, und wenn man es nicht mag ... nun, der Cheeseshop ist groß.

Naja, du sagst halt was dir an Pylons gefällt (vllt. auch im Hinblick auf die Vor und Nachteile der anderen) und beschreibst wenigstens was es ist. Im Moment ist das ja nur ein Link auf dessen Homepage, der Informationshegalt zu Pylons tendiert also gegen Null. Ein solcher Überblick ist durchaus nett, wenn wieder jemand fragt, was er nehmen soll - da werden ja immer die gleichen Argumente verwendet und so kann man gleich eine Seite im Wiki anlegen wo es einmal etwas ausfühlicher beschrieben ist.

Der Abschnitt mit World Online kann wohl auch gestrichen werden, Ellington interessiert eigentlich niemanden.

[lunar]

Und was soll ich da jetzt schreiben bzw. welche Kriterien soll ich für eine wie auch immer geartete Beurteilung von Pylons anwenden? Pylons selbst ist doch nichts außer ein bisschen Convention um Paste herum in Verbindung mit einer (unverbindlichen) Auswahl an Bibliotheken und einem sehr hübschen Webdebugger. Pylons selbst hat keine Template-Engine, kein ORM, kein Authentifizierungsmodul und keine Formbibliothek. Man nimmt halt, was Pylons empfiehlt, und wenn man es nicht mag ... nun, der Cheeseshop ist groß.

Naja, du sagst halt was dir an Pylons gefällt (vllt. auch im Hinblick auf die Vor und Nachteile der anderen)

Irgendwie habe ich den Eindruck, dass du nicht wirklich gelesen hast, was ich geschrieben habe. Paste gefällt mir. SQLAlchemy gefällt mir. Jinja2 ist toll. Aber an Pylons finde ich nur die Konventionen gut und mag den Debugger. Was sollte ich sonst auch mögen, Pylons selbst ist doch nicht mehr. So gesehen gefällt mir persönlich an Pylons, dass es denimho richtigen Weg zwischen Konvention und Flexibilität findet. Das ist allerdings in höchstem Maße subjektiv.

beschreibst wenigstens was es ist.

Na, wenns dir gefällt ... done.