Das deutsche Python-Forum

Fallen][Angel hat geschrieben:Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.

Hm? Kannst du das ein wenig mehr ausführen?

jens hat geschrieben:
Fallen][Angel hat geschrieben:Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.
Hm? Kannst du das ein wenig mehr ausführen?

Code: Alles auswählen

class ReadingOccasion(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book, edit_inline=models.STACKED,
        num_in_admin=1)

Code: Alles auswählen

class Reading < ActiveRecord::Base
  belongs_to :book
  belongs_to :reader
end

Da muss ich zugeben, dass ich RoR von seiner Konfiguration irgendwie schlanker und übersichtlicher wirkt.

Abnehmen tun beide Framework wohl die gleiche Arbeit, war vielleicht falsch formuliert. Es bleibt aber, dass ich finde, das Python da für den gleichen Effekt etwas mehr tippen verlangt

Eher:

Code: Alles auswählen

class Reading(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book)

Das es in deinem Beispiel länger ist, liegt daran, dass du da Sachen für den Django Admin konfigurierst. Was RoR ja nicht hat, also für einen fairen Vergleich musst du das wegnehmen. Und die Klassen in Django drei mal länger zu nennen als in Rails ist natürlich auch nicht so toll zum Vergleich.

Okay, dass das für den Admin war, wusste ich so noch nicht direkt. Soll dann nicht zu Lasten von Django gehen

Wenn man es so aber runterkürzt sieht es schon kürzer aus

Grundsätzlich sieht das von RoR auch einfach "schlanker" aus, weil ich das schon kenne.

Es kommt auch darauf an, wie man den import gestaltet.

Die alte Variante:

Code: Alles auswählen

from django.db import models

class Reading(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book)

So müßte es aber auch gehen:

Code: Alles auswählen

from django.db.models import Model, ForeignKey

class Reading(Model):
    reader = ForeignKey(Reader)
    book = ForeignKey(Book)

Ich mache das aber auch nach der ersten Variante.

Wie sehen denn bei Ruby die imports aus? Also woher kommt "belongs_to"?

In RoR kommt dies automatisch durch "ActiveRecord::Base". Um alles weitere kümmert sich RoR dann selbst.

Da bleibe ich lieber bei:

Explicit is better than implicit.

Siehe auch: http://www.python.org/dev/peps/pep-0020/

Mit etwas Metamagie ließe sich das eine Funktion ``belongs_to`` auch in Django machen. Aber das wiederspricht eigentlich der Philosophie von Python, wo eine explizite Zuweisung besser ist, als Magie die unter der Haube funktioniert.

Fallen][Angel hat geschrieben:
Y0Gi hat geschrieben:Es mag in der Praxis funktionieren, aber mir ist keineswegs wohl dabei, einen Cronjob zu haben, der ein, zweimal am Tag (spätestens) FastCGI-Prozesse abschießt.
Quellen dafür?

Einiges kommt aus persönlichem Kontakt, andere Belege finden sich z.B. in diesen beiden, ja, Rants:

Rails Is A Ghetto (Abschnitt "How’d This Happen?", ~sechster Absatz)

The main Rails application that DHH created required restarting _400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.

How Ruby on Rails Could Be Much Better

Es gibt auch einen Vortrag vom 24c3, in dem einige Dinge über RoR Sicherheit gesagt werden.

Vieles davon ist gewöhnlich (CSS- und CSRF-Attacken, SQL Injection, etc), aber am Schluss kommt der Mensch auch auf DoS-Angriffe auf RoR Seiten zu sprechen.

RoR ist offenbar nicht multithreaded, nutzt also für jeden Request einen separaten Prozess. Offenbar ist die Anzahl der Handler-Prozesse allerdings limitiert, auf ~8 Prozesse pro CPU. Die Konsequenz dessen ist, dass ein aufwändiger Request-Handler-Code (der Vortrag nennt u.a. Bildbearbeitung, Mass Mailing und Up-/Downloads als Beispiele) die Zahl der Handler-Prozesse effektiv reduziert. Auf diese Weise kann man Rails-Seiten über massenhafte Requests anscheinend relativ leicht lahmlegen.

Ich habe keine Ahnung, ob das nun in der Realität wirklich so einfach ist, aber allein die Tatsache, dass die Anzahl der Handler-Prozesse limitiert ist, widerspricht der Aussage "Rails skaliere gut" ein bisschen

Ich halte Python für einfacher erlernbar als Ruby. In der Firma hatte ich mich nach längerer Überlegung gegen Ruby und für Python entschieden und wir waren nach nicht einmal 2 Wochen produktiv mit Django unterwegs. Das wäre mit Rails in unserer Konstellation nicht möglich gewesen. Ich kannte zuvor bereits Ruby und Rails, Python und Django waren auch auf mich neu.

An Django stört mich eigentlich nur der Starrsinn der Entwickler, keine regelmäßigen Releases zu machen. Ansonsten war das für unseren Anwendungsfall einer eher klassischen Webseite mit Community-Features sehr gut geeignet.

Würde ich jetzt ein Spiel bauen wollen - wozu ich zwar mal Lust hätte, aber nicht die Zeit dazu habe - würde ich wohl etwas anderes nehmen, da Django hier seine Stärken nicht so ausspielen kann. Dennoch wäre auch dort Python eine gute Wahl.

Übrigens, Pylons hat mich nicht überzeugt - zu viel Auswahl. Wir hatten uns das einen Tag lang angeschaut und der erste Kollege war immer noch nicht mit der Konfiguration des System fertig als der zweite bereits mit Django vollzug melden könnte ;) Und wir suchten in erster Linie etwas, um in extrem kurzer Zeit etwas prototypisieren zu können.

Übrigens, bei Ruby sind glaube ich Merb und DataMapper einen Blick wert. Beides wirkt ein bisschen wie Pylons in dem Sinn, dass der Anspruch zu kombinierbaren wiederverwendbaren Komponenten da ist, aber ansonsten scheint dort viel eingeflossen zu sein, was bei Rails eben nicht so toll ist. Ich weiß allerdings gerade nicht, ob Merb schon mit JRuby funktioniert, welches sich ja tatsächlich zur schnellsten Alternative entwickelt hat, was Rails Deployment angeht.

Übrigens, wenn man sich

Code: Alles auswählen

def belongs_to(n):
	globals()[n] = models.ForeignKey(globals()[n].capitalize())

definiert, könnte man wohl (ohne das ich das jetzt ausprobiert habe) auch folgendes in Django benutzen:

Code: Alles auswählen

class Reading(models.Model):
  belongs_to("book")
  belongs_to("reader")

Allgemein ist der Python-Stil aber immer etwas expliziter und weniger magisch als Rails es mag.

Noch ein Punkt: Ich teile mitsuhiko Abneigung gegen MVC nicht. Eine Zeit lang hat es mich gestört, dass die von Sun geprägte Definition eigentlich recht wenig mit dem Original von Trygver, wie man sie im ursprügnlichen Smalltalk findet, zu tun hat, aber dann habe ich akzeptiert, dass eben die Geschichte von den Siegern geschrieben wird. Letztlich heißt es ja nur, dass ich Modell und Darstellung trenne und bei Webanwendungen jetzt nochmal das Verarbeiten der Request von der Aufbereitung der Webseite.

Stefan

Ich nehme an, dass mitsushiko darauf hinaus will, dass im Web-Bereich eher MTV (Model, Template, View[-Funktion]) zutrifft als MVC (wo ein Controller mehrere Views haben kann; im Web-Bereich sind etwa XHTML, PDF, ATOM, XML und JSON denkbar, aber zumindest nicht der Normalfall) und evtl. noch weitere Unterschiede, es also auf eine Frage der korrekten Terminologie hinausläuft.

Nach langem Überlegen habe ich mich dann mal dazu durchgerungen, dass ich mir Python ansehe und bis jetzt ist es eigentlich gar nicht schlecht

Persönlich find ich dieses lesen von Diving into Python etwas anstrengend, weil ich z.B. auch mal gerne auf der Couch liegen würde oder nicht so sehr an den PC gebunden wäre.

Daher suche ich noch nebenbei, als Ergänzung, ein deutsches Buch. Hier wurde ja schonmal eine Seite verlinkt, welche 4 Bücher vorgestellt hat, aber irgendwie soll jedes davon so seine Macken haben...

Was haltet ihr eigentlich hiervon: Klick

Fallen][Angel hat geschrieben:Persönlich find ich dieses lesen von Diving into Python etwas anstrengend, weil ich z.B. auch mal gerne auf der Couch liegen würde oder nicht so sehr an den PC gebunden wäre.

Um es mit Marks Worten zu sagen: Buy the cow.

Habe aus dem Thread http://www.python-forum.de/topic-5239.htm das erste Buch. Ist ok.

Btw. irgendwann wird es auch ein deutsches django Buch geben: http://www.python-forum.de/topic-11908.htm

Ach, noch was zum Thema Frameworks... Hab in der c't den Artikel über Grails gelesen: http://de.wikipedia.org/wiki/Grails
Eigentlich ganz nett. Aber im Grunde hat man in django eigentlich auch alle Features, die Grails hat. Darüber hinaus ist django in der Serveranbindung flexibler...

Das deutsche Python-Forum

Webapplikation: Shop in welcher Sprache/Framework?