Das deutsche Python-Forum

Ich quäle mich gerade mit der verglichen mit Bottle sehr komplizierten Art, wie Django URLs routet. Leider wollen bei mir die ersten Codeschnipsel vom Django-Tutorial nicht funktionieren:

ImportError at /polls/

cannot import name urls

Request Method: GET
Request URL: http://localhost:8000/polls/
Django Version: 1.8.3
Exception Type: ImportError
Exception Value:

cannot import name urls

Exception Location: /home/nuc/djangotutorial/mysite/polls/urls.py in <module>, line 1
Python Executable: /home/nuc/djangotutorial/venv/bin/python
Python Version: 2.7.9
Python Path:

['/home/nuc/djangotutorial/mysite',
'/home/nuc/djangotutorial/venv/lib/python2.7',
'/home/nuc/djangotutorial/venv/lib/python2.7/plat-x86_64-linux-gnu',
'/home/nuc/djangotutorial/venv/lib/python2.7/lib-tk',
'/home/nuc/djangotutorial/venv/lib/python2.7/lib-old',
'/home/nuc/djangotutorial/venv/lib/python2.7/lib-dynload',
'/home/nuc/anaconda/lib/python2.7',
'/home/nuc/anaconda/lib/python2.7/lib-tk',
'/home/nuc/djangotutorial/venv/lib/python2.7/site-packages']

Server time: Sat, 18 Jul 2015 12:00:42 +0200

Ursache?

Ich tippe auf einem Fehler in deinem Quelltext.

Das Beispiel aus den Django-Tutorial funktioniert, habe das Tutorial selbst erst durchgearbeitet.

@meego: hast Du denn eine __init__.py-Datei im polls-Verzeichnis?

Korrekt. Muss mich irgendwo verschrieben haben. Gibt's eigentlich ein abgespecktes Django?

meego hat geschrieben:Gibt's eigentlich ein abgespecktes Django?

Wenn du nicht alles aus Django verwendest, dann kannst du es in der Benutzung selber abspecken wie du willst. Auf der anderen Seite stellt sich dann die Frage, warum man eigentlich Django verwendet.

Was möchtest du denn eigentlich erreichen?

@/me:

Etwas ähnliches wie: Homegate.ch.
Ich habe heute versucht Teil 3 vom Djangotutorial zu lesen. Hier wird mir das Tutorial definitiv zu kompliziert und unlesbar. Zu viele Ordner, zu viele Abhängigkeiten (die ich nicht durchschaue), zu viele Verschachtelungen, und Regex benötige ich wohl auch nicht. Intuitiv ist das alles bis jetzt leider gar nicht.

meego hat geschrieben:Ich habe heute versucht Teil 3 vom Djangotutorial zu lesen. Hier wird mir das Tutorial definitiv zu kompliziert und unlesbar.

Wenn das dein Verständnisniveau übersteigt dann nimm ein leichtgewichtigeres Framework. Ohne Views und Templates hat der Einsatz von Django meiner Meinung nach keinen Sinn.

meego hat geschrieben: Ich habe heute versucht Teil 3 vom Djangotutorial zu lesen.

Lesen wird vermutlich nicht ausreichen. Ich würde nochmal ein paar Schritte zurückgehen und das wirklich auch ausführen. Gerne mehrfach, bisschen rumspielen, bis es klar wird. Bei Fragen wieder hier melden.

Hallo

Ich habe Kapitel 1-2 schon auch ausgeführt. Wobei ich das schon noch festigen müsste.

Allerdings bestätigen meine Erfahrungen auch sehr viele Stimmen in diesem Faden. Ich glaube, ich bin (vielleicht auch als Newbie) eher der Lego-/Bottom-up-Typ. Ich denke auch, ich lerne mit Bottle oder Flask mehr dabei. Wobei es für Flask wahrscheinlich mehr Tutorials gibt. Ein Nachteil sind vermutlich die Migrationen. Templates hat auch Bottle, aber die müssen dort nicht erst an 2 unterschiedlichen Stellen in einem frameworkspezifischen Format hinterlegt werden.

@meego: alle Frameworks arbeiten nach dem selben Prinzip. Eine URL wird aufgelöst (Routing) zu einer bestimmten Methode, die aufgerufen wird und als Ergebnis Text liefert, der an den Client zurückgesendet wird. Django spaltet dieses Routing auf mehrere Ebenen auf, um sein App-Konzept umsetzen zu können. Bei nur einer App, wie es am Anfang üblich ist, scheint dieses Vorgehen unnötig kompliziert, da sind Frameworks, die direkt routen scheinbar einfacher. Sobald ein Projekt aber größer wird, und man mehr modular entwickeln möchte, sieht man die Vorteile von Django.

Templates haben ein templatespezifisches Format. Die Frameworks unterscheiden sich hier nur, wie einfach sich alternative Templateengines einbinden lassen. Wie kommst Du darauf, dass man bei Bottle das gleichzeitig auf zwei unterschiedliche Arten machen müsste?

Django bringt sein eigenes ORM mit, für die anderen solltest Du auf SQLAlchemy aufbauen. Hier scheint Django für den Anfänger auch wieder komplizierter zu sein, bietet dafür aber automatische Migration, eingebaute Modularisierung und ein Verwaltungswebinterface. Alles Dinge, die Du vielleicht am Anfang nicht brauchst, später aber bei den anderen Frameworks Dir eigene Lösungen basteln mußt.

Natürlich ist ein micro framework erstmal einfacher zu überblicken. Aber es bleibt nur überschaubar, wenn man nicht all zu viele zusätzliche Komponenten braucht. Doch schnell braucht man mehr. Dann ist zuerst die frage was. Nimmt man denn nun?!? Dann hat man verschiedene Dokumentationen und muss für die Zusammenarbeit selber sorgen.

Es kann also IMHO schnell komplizierter als Django werden...

Hallo,

IMHO ist das Django-Routing nur unwesentlich komplizierter als das von Bottle. Bei Bottle wirkt es übersichtlicher, weil man pro Funktion eben einen Dekorator hat, während bei Django alles in der `urls.py` steht. Letzteres macht es aber übersichtlicher, wenn das Projekt größer wird

Hier wird mir das Tutorial definitiv zu kompliziert und unlesbar.

Na ja, also das Django-Tutorial ist IMHO schon sehr gut geschrieben. Klar, wenn alles neu ist, dann muss man halt vielleicht 2 oder 3 mal lesen, um alles zu verstehen. Mir selber hat bei meinem Start sehr "learning by doing" geholfen. Heißt: ich habe die Beispiel-App aus dem Tutorial erst gar nicht nachprogrammiert, sondern direkt was eigenes geschrieben (was nur lokal läuft, von daher kein Zwang auf "production-ready" .

Ansonsten lies' zuerst das "Django for Girls Tutorial (http://tutorial.djangogirls.org/en/index.html), ab Kapitel 7 oder 9. IMHO sehr gut und sehr verständlich geschrieben! Auch für boys & men

Gruß, noisefloor

Hi

noisefloor hat geschrieben: IMHO ist das Django-Routing nur unwesentlich komplizierter als das von Bottle. Bei Bottle wirkt es übersichtlicher, weil man pro Funktion eben einen Dekorator hat, während bei Django alles in der `urls.py` steht. Letzteres macht es aber übersichtlicher, wenn das Projekt größer wird

Möglich, aber schade ist, dass man es nicht nur in einem URL-File ändern muss, sondern gleich in zwei Stellen (ich frage mich, ob das wirklich notwendig war, oder nicht einfach nur unnötig kompliziert strukturiert). Djangogirls fand ich von den paar Kapiteln auch etwas allgemeinverständlicher. Aber ich denke, ich werde erst später darauf zurückkommen, mich auf die etwas eigenen Konzepte von Django einzulassen.

@meego: ich glaube, das was Du da versucht hast, war unnötig kompliziert und nicht notwendig. Weil Du nicht sagst, was Du gemacht hast, kann man hier auch nicht sagen, warum Du das so umständlich gemacht hast und wie es richtig geht.

meego hat geschrieben:Möglich, aber schade ist, dass man es nicht nur in einem URL-File ändern muss, sondern gleich in zwei Stellen

Das muss man nicht. Zumindest sollte man das nicht müssen. In welchem Kontext ist dir das denn untergekommen?

Ich beziehe mich auf:
"The next step is to point the root URLconf at the polls.urls module. In mysite/urls.py insert an include(), leaving you with:
mysite/urls.py"
Gemäss: Link. Okay, die zweite Änderung muss man wohl nur einmal für jede Applikation machen, dennoch ist es mühsam (darum könnte sich Django ja auch im Hintergrund kümmern).

Im Tutorial geht es darum etwas nach und nach zu erweitern...

Die include() Geschichte ist super praktisch. Man könnte aber auch alles in einer urls.py machen, ist aber unpraktisch

Du kannst mal davon ausgehen, das alles in Django schon gut durchdacht ist. Einfach mal hinnehmen.
Einige Dinge kommen allerdings erst später zum zug. Für super einfache Dinge mag das alles ein wenig "aufwendig" vorkomme. Aber wie lange bleibt es bei einer super einfachen App?!?

meego hat geschrieben:Okay, die zweite Änderung muss man wohl nur einmal für jede Applikation machen, dennoch ist es mühsam (darum könnte sich Django ja auch im Hintergrund kümmern).

Für mich wäre es böse schwarze Magie wenn Django plötzlich lauter Dateien namens url.py die es irgendwo findet automatisch einbinden würde.

Stimmt und dekoratoren an den views würden "reuseable apps" auch nicht so einfach ermöglichen.