Das deutsche Python-Forum

Ian Bicking bezeichnet Paste als "Metaframework". Generell ist eine Namensfindung nicht so einfach. Für mich sind Paste und Werkzeug das, was ihren Kern darstellt und sie für mich interessant macht: WSGI-Implementierungen, die mir die Schnittstelle in Form von hübschen Request- und Response-Objekten anbieten. Der Rest ist, für diesen Layer, nur Zubehör - der nicht zu Unrecht auch ausgelagert wird (s. WebOb, werkzeug.contrib), allerdings auch meist zu trivial für ein eigenes Paket ist.

"Framework" geht als Begriff schon Richtung Buzzword, da es *sehr* vieles Bedeuten kann und (entsprechend des Wortes an sich) kaum genau definiert ist. Im Web-Applikationsbereich sind Frameworks meiner Erfahrung nach in der Regel Vorselektionen und Integration von Komponenten für einzelne Aufgaben.


Was die Debugging-Middleware von Werkzeug angeht: Lässt die sich nicht einfach in Django "einschieben"? Es ist schließlich eine WSGI-Middleware. Ich nutze sie selbst auch in Projekten, die nicht auf Werkzeug aufsetzen.

Y0Gi hat geschrieben:Was die Debugging-Middleware von Werkzeug angeht: Lässt die sich nicht einfach in Django "einschieben"? Es ist schließlich eine WSGI-Middleware. Ich nutze sie selbst auch in Projekten, die nicht auf Werkzeug aufsetzen.

An sich: ja. Jedoch sind Django-Middlewares nicht WSGI-Middlewares. Du kannst also einen WSGI-Traceback einschieben, aber die Idee war ja, den Prompt in den bereits existierenden, recht hübschen Traceback einzubauen.

Jep, ein Traceback Debugger wurde aber werden sicherheits Bedenken nicht realisiert, siehe: http://code.djangoproject.com/ticket/3527

Das ganze als Django-Middleware zu realisieren wäre doch eigentlich schön...