Das deutsche Python-Forum

Das mit "self" ist ehr ein Witz, genauso wie manche das Einrücken als dumm ansehen.

Mit self überreicht man in Klassen Klassenweite Objekte. Blödes Beispiel:

Code: Alles auswählen

class BSP:
    def __init__(self, txt):
        self.txt = txt

    def zeigmal_txt(self):
        print self.txt

bsp = BSP("Beispieltext")
bsp.zeigmal_txt()

Zum Thema django, lies dir mal auf [wiki]Web-Frameworks#Django[/wiki]im Abschnitt django den Punk "Nachteile" durch...
Django wird leider recht wenig released. Deswegen nutzt IMHO fast niemand die alten Releases, sondern man nutzt einen SVN checkout vom trunk. Das ist aber ok, weil der trunk sehr stabil ist. Man muß nur hin und wieder auf die Seite mit den Änderungen schauen und diese einpflegen: http://code.djangoproject.com/wiki/Back ... bleChanges
Das mache ich so und fahre eigentlich ganz gut damit.

Was man vielleicht nicht anfangen sollte, irgendwelche noch nicht eingepflegte Patches in seiner App zu nutzten. Dann wird es natürlich haarig...

Also müsste ich bei einer Klasse, wenn ich auf Variablen der Instanz zugreifen will, immer self als Übergabeparameter vorsehen?

Grundsätzlich ist viel davon natürlich wieder ein Glaubenskrieg [...]
Zum einen wird bei Python bzw. Django häufig das "self" angekreidet.

Genau sowas ist ein Glaubenskriegsgrund. Alternativ könnte man ruby das @ ankreiden. "Sieht aus wie ein Perlsches Smileygemetzel"

Aber allgemein sollten RoR und Django wohl ungefähr gleich auf liegen.

Dem Hörensagen nach soll RoR nicht gerade gut Skalieren. Ja, kann gut ein Gerücht sein, aber wenn das self als "beitrag" zur Diskussion gilt...

keppla hat geschrieben:"Sieht aus wie ein Perlsches Smileygemetzel"

Den muss ich mir merken

Dem Hörensagen nach soll RoR nicht gerade gut Skalieren. Ja, kann gut ein Gerücht sein, aber wenn das self als "beitrag" zur Diskussion gilt...

RoR forkt iirc eine feste, limitierte Anzahl an Request-Handler-Prozessen. Liefert man große Response wie beispielsweise Software-Downloads aus, kann man RoR-Anwendungen, sofern keine zusätzlichen Schutzmaßnahmen getroffen wurden, relativ einfach lahmlegen.

keppla hat geschrieben:Dem Hörensagen nach soll RoR nicht gerade gut Skalieren.

Das haben einige aufgezeigt. z.b.:
http://wiki.rubyonrails.com/rails/pages ... erformance
Hatten wir hier diskutiert: http://www.python-forum.de/topic-10152.html

EDIT: Noch ein alter Artikel gefunden:
http://www.alrond.com/en/2007/jan/25/pe ... rameworks/

Vielleicht auch noch interessant: "A Rails/Django Comparison": http://docs.google.com/View?docid=dcn8282p_1hg4sr9

jens hat geschrieben:
keppla hat geschrieben:Dem Hörensagen nach soll RoR nicht gerade gut Skalieren.
Das haben einige aufgezeigt. z.b.:
http://wiki.rubyonrails.com/rails/pages ... erformance
Hatten wir hier diskutiert: http://www.python-forum.de/topic-10152.html

EDIT: Noch ein alter Artikel gefunden:
http://www.alrond.com/en/2007/jan/25/pe ... rameworks/

Vielleicht auch noch interessant: "A Rails/Django Comparison": http://docs.google.com/View?docid=dcn8282p_1hg4sr9

Ich hab mir einige davon, werd mich jedoch noch alle, einmal ansehen. Jedoch muss ich sagen, dass nun absolute Geschwindigkeit bei mir nicht primär im Vordergrund steht, jedoch es ist gut sowas mal zu sehen.

Mir kommts aber eher auf die Sprache und ihre Qualitäten als solche an.

Fallen][Angel hat geschrieben:Ansonsten wird oft gesagt, dass django noch sehr in der Entwicklung sei und man häufig immer nur mit der svn-Version arbeiten muss, was zur folge hat, dass man oft irgendwelchen Änderungen am Framework unterlegen ist. Hacks für Bugs sollen angeblich auch öfters nötig sein.

Naja, manchmal trifft man durchaus auf Bugs, aber wir wollen nicht übertreiben - das passiert nicht so oft. Es sind eher Designentscheidungen, die einen stören. Die wird es in RoR wohl auch geben.

Was die SVN-Version angeht: stimmt, wenn du neue Features verwenden willst, dann solltest du die SVN-Version einsetzen. Aber meiner Erfahrung nach ist die durchaus für den Produktiven Gebrauch nutzbar, da die Releases recht alt sind. Wenn aber etwas eingeführt wird, was alten Code bricht, dann wird das dokumentiert - da gibt es eine Wiki-Seite zu dem Thema. Ist in meinen Augen eigentlich kein Problem.

`self` bei Python ist ähnlich dem `end` bei Ruby - mit dem Unterschied, das ersteres keine eigene Zeile verschwendet

`end` mag ich nicht, doch wenn ich das so lese und bedenke, dass ich mich an `self` gewöhnt habe, dann ist das sicherlich zu verschmerzen und mit Disziplin eine Frage der Gewohnheit, was umgekehrt wieder für Pythons Whitespace-Awareness gelten dürfte.

`self` gibt es wegen "explicit is better than implicit". Der Name ist dabei völlig egal und `self` nur Konvention. Tatsache ist, dass alle Objektmethoden es als erstes Argument erhalten (Klassenmethoden erhalten stattdessen eine Referenz auf die Klasse, statische Methoden keins von beiden).

Man sollte durchaus zwischen Sprache und Framework unterscheiden. So mag ich Python sehr, aber Django fast gar nicht (leider gibt es keine brauchbare Alternative an vorgefertigten Full-Stack-Frameworks, was für mich jedoch egal ist). In der Ruby-Liga gibt es ebenso welche, die Ruby lieben, aber statt Rails lieber auf andere (oder keine, es gibt ja noch mehr Anwendungsgebiete als das Web) Pakete wie Nitro oder Camping(?) setzen. Gerade durch den RoR-Hype werden Framework und Sprache aber sehr oft in einen Topf geworfen und synonym verwendet.

P.S.: Über drastische Probleme beim Rails-Deployment bei großen und kleinen Setups habe ich zuletzt auch zahlreiche Artikel abgeklappert. Offenbar sind Mongrel und auch das (frühere) Rails-eigene Deployment (iirc?) für Speicherlecks anfällig. 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.

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?

Also alles im allen muss ich sagen: PHP ist derzeit wohl das Schlusslicht bei meiner Auswahl - wundert mich jedoch nicht wirklich

Nun kommt es zu Platz 1 und 2 und genau hier liegt das Problem: Im Endeffekt arbeiten beide Sprachen sehr solide und die Frameworks dazu verrichten ihren Dienst ebenso erfolgreich. Oft hängt es dann wohl an Kleinigkeiten, je nachdem, wie man seinen Fokus legt: Geschwindigkeit, Syntax der Sprache, gewisse Features, etc.

An RoR stört mich z.B., dass es keine wirkliche Möglichkeit für Mehrsprachigkeit gibt und sowas würde ich eigentlich von einem guten Framework erwarten. Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.

Daher bin ich (noch immer) leicht unentschlossen, wer nun auf Platz 1 meiner Vorlieben darf und wer auf Platz 2

@Fallen][Angel: Also ich mag Ruby nicht. Das "fühlt" sich für mich sehr anders an als Python. Und ich glaube das geht nicht nur mir so, und gilt mit umgekehrten Vorzeichen auch für viele(?) Ruby-Programmierer. Also ist wohl die persönliche Vorliebe hier nicht ganz unwichtig. Wenn Dir sonst keine wichtigen Entscheidungskriterien mehr bleiben, dann würde ich an Deiner Stelle einfach mal ein kleines Testprojekt in beiden Sprachen implementieren und schauen welche Sprache (+Webframework) Deiner "Denke" eher entgegen kommt.

BlackJack hat geschrieben:@Fallen][Angel: Also ich mag Ruby nicht. Das "fühlt" sich für mich sehr anders an als Python. Und ich glaube das geht nicht nur mir so, und gilt mit umgekehrten Vorzeichen auch für viele(?) Ruby-Programmierer. Also ist wohl die persönliche Vorliebe hier nicht ganz unwichtig. Wenn Dir sonst keine wichtigen Entscheidungskriterien mehr bleiben, dann würde ich an Deiner Stelle einfach mal ein kleines Testprojekt in beiden Sprachen implementieren und schauen welche Sprache (+Webframework) Deiner "Denke" eher entgegen kommt.

Darauf wird es vermutlich auch hinauslaufen. Ich habe mich schonmal nach guten Lernquellen umgesehen und bin am Pythonbuch von Galileo-Computing hängen geblieben.

Gibt es netterweise als OpenBook, wodurch ich es mir kostenlos ansehen kann.

@Fallen][Angel: Iiih da bist Du dann gleich an einem schlechten Buch hängen geblieben. Daraus wirst Du kein idiomatisches Python lernen können, sondern eines wie ein C++- oder Java-Programmierer Python schreiben würde, ohne sich damit wirklich auseinander gesetzt zu haben.

Für den Einstieg ist das Tutorial in der Python-Dokumentation eine ganz nette Tour durch die Sprache. Ein anderer guter, freier Text für Leute mit schon etwas Programmiererfahrung ist "Dive Into Python".

Gratulation: Du hast das wohl schlechteste Buch über Python entdeckt!

An deiner Stelle würde ich mir eine andere Lektüre wie "Diving into Python" suchen

Oha, hätte ich nicht gedacht, dass das Buch so schlimm ist

Sah auf den ersten Blick eigentlich recht solide aus.

Ansonsten noch irgendwelche Tipps, wo es nette und gute Lektüre gibt, welche sich einsteigerfreundlich verhält?

Fallen][Angel hat geschrieben:Ansonsten noch irgendwelche Tipps, wo es nette und gute Lektüre gibt, welche sich einsteigerfreundlich verhält?

Hallo FA!

http://halvar.at/python/einstieg_in_python/

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"?

Das deutsche Python-Forum

Webapplikation: Shop in welcher Sprache/Framework?