Flask: Micro Web Framework based on Good Intentions

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Wenns schon mal ein grosseres kleines neues Pocoo Projekt gibt kann man das ja hier announcen :) Ausgeloest durch meinem diesjaehrigen Aprilscherz (Denied) gibts jetzt ein ernsthaftes und gutgemeintes Microframework auf Basis von Werkzeug und Jinja2.

Darf ich vorstellen? Flask, ein Micro Web Framework fuer Python.

Wie schauts aus?

Code: Alles auswählen

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()
Und so lauefts dann auch:

Code: Alles auswählen

$ easy_install Flask
$ python hello.py
 * Running on http://localhost:5000/
Warums das gibt und warum es so aussieht sieht man in den Designerklaerungen: http://flask.pocoo.org/docs/design/

Webseite: http://flask.pocoo.org/
Dokumentation: http://flask.pocoo.org/docs/
Github: http://github.com/mitsuhiko/flask
Beispielanwendungen: http://github.com/mitsuhiko/flask/tree/master/examples/
TUFKAB – the user formerly known as blackbird
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Wie sieht es aus mit der Stabilität? "Alpha" erscheint mir ein bisschen untertrieben ;)
Der aktuelle Stand kann schon als brauchbare Alternative zu anderen Frameworks (wie z.B. bottle) gesehen werden, oder?
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher

http://ms4py.org/
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Gefällt mir sehr gut.
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Warum eigentlich der Alleingang? Hätte es nicht gereicht, an Bottle anzuknüpfen? Eure APIs sind doch fast identisch.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

snafu hat geschrieben:Warum eigentlich der Alleingang? Hätte es nicht gereicht, an Bottle anzuknüpfen? Eure APIs sind doch fast identisch.
Der Alleingang ist hier eher Bottle das WSGI selbst implementiert und nicht auf WebOb oder Werkzeug zurueckgreift. Flask ist selbst keine 500 Zeilen lang. Bottle's Ziel ist es ein ein-Datei Framework zu sein, da kann Flask nicht mithalten und da will ich auch nicht hin.

Im Uebrigen steht auch in den Design-notes warum das Interface nith so aussieht wie das von Bottle, sondern eben etwas anders.

Wie bereits in den Docs erwaehnt ist Flask nur ein schickes Frontend zu Werkzeug und Jinja2 um den Einstieg zu erleichtern (und jede Menge - hoffentlich leicht zu lesende - Dokumentation)
ms4py hat geschrieben:Wie sieht es aus mit der Stabilität? "Alpha" erscheint mir ein bisschen untertrieben.
Der aktuelle Stand kann schon als brauchbare Alternative zu anderen Frameworks (wie z.B. bottle) gesehen werden, oder?
Das Alpha steht fuer: Experimentierungsphase, nicht das es Instabil ist. Werkzeug existiert schon lange und laueft schon laenger als Basis vieler Webseiten.
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

snafu hat geschrieben:Warum eigentlich der Alleingang? Hätte es nicht gereicht, an Bottle anzuknüpfen?
Nein, also bottle will ja möglichst klein sein (früher solltens unter x LOC sein, weiß nicht ob das immer noch so ist) und das ist genau das was ich nicht will. Daher bin ich froh dass es Flask gibt, was schon eher in die von mir gewünschte Richtung geht. Plus gute Integration mit den anderen Pocoo-Projekten, die ich sowieso schon nutze.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Leonidas hat geschrieben:
snafu hat geschrieben:Warum eigentlich der Alleingang? Hätte es nicht gereicht, an Bottle anzuknüpfen?
Nein, also bottle will ja möglichst klein sein (früher solltens unter x LOC sein, weiß nicht ob das immer noch so ist) und das ist genau das was ich nicht will. Daher bin ich froh dass es Flask gibt, was schon eher in die von mir gewünschte Richtung geht. Plus gute Integration mit den anderen Pocoo-Projekten, die ich sowieso schon nutze.
Ich denke beides hat seine Berechtigung. Bottle läuft einfach ohne weitere Installationen und flask hat ein mächtiges Framework im Rücken.

AFAIR wollte defnull <1000 LOC bleiben, ist aber inzwischen (deutlich) drüber.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Schön wäre allerdings noch eine vereinfachte Integration eines Datenbank Toolkits, das es Einsteigern relativ einfach ermöglicht auf eine entsprechende DB-Sessions zuzugreifen.

Solche Microwebframeworks sind ja vor allem für kleine Sachen gedacht, die man ohne großen Aufwand und schnell fertigstellen will. Hier fehlt IMHO eine gute Datenbank-Anbindung, die sich unkompliziert konfigurieren lässt.

SQLAlchemy wäre vllt. als weitere Abhängigkeit ziemlich groß, aber würde so ein Framework abrunden.
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Man kann die SQLAlchemy doch nutzen, wenn man will.
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

ahojnnes hat geschrieben:Schön wäre allerdings noch eine vereinfachte Integration eines Datenbank Toolkits, das es Einsteigern relativ einfach ermöglicht auf eine entsprechende DB-Sessions zuzugreifen.
SQLAlchemy mit ins Boot nehmen ist was, das ich nicht vor hab. Vor allem weil SQL ja nicht mit Webanwendung untrennlich verbunden ist. In den Docs sind drei wege SQLAlchemy einzubinden, ich glaub das ist nicht zu kompliziert: http://flask.pocoo.org/docs/patterns/sqlalchemy/
TUFKAB – the user formerly known as blackbird
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

jo, klar... wobei man ja theoretisch so etwas implementieren könnte:

Code: Alles auswählen

class Flask(object):
    def __init__(self, app_name, db_engine=False):
        # ...
und damit die Abhängigkeit nur im Falle der Benutzung in Kraft tritt. Die Frage, die man sich stellen muss, ist: soll Flask wirklich nur ein >>Micro<<-Webframework sein oder einfach ein Tool, welches es einem erleichtert kleine Webapps zu schreiben ohne sich groß Gedanken zu machen, wie man das "implementiert".

Und genau hier denke ich, könnte Flask ansetzen, da es ja bereits auf Werkzeug und Jinja2 aufbaut (zwei wirklich sehr gute und vor allem mächtige Tools) und damit das >>Micro<< schon wegfällt. Mir geht es dabei auch nicht um kompliziert, sondern in welcher Zeit kann ich eine App bauen, die trotzdem auf Komponenten basiert, die mir vertraut sind und mittlerweile sehr ausgereift.

Aber wie gesagt, ist das nur meine Meinung.
Benutzeravatar
Defnull
User
Beiträge: 778
Registriert: Donnerstag 18. Juni 2009, 22:09
Wohnort: Göttingen
Kontaktdaten:

@Flask/Bottle:
Ich hatte eigentlich vor, WebOb.Request und werkzeug.Request in Bottle als alternative zum eingebauten bottle.Request zu unterstützen. Für Server und Templates (auch Jinja2) gibt es diese Auswahlmöglichkeiten ja schon länger. Wenn man nun bedenkt, das der einzige wirkliche Unterschied im API Design bei genauerer Betrachtung keiner mehr ist (auch Bottle unterstützt den app-Objekt orientierten Ansatz, er ist nur schwächer dokumentiert) finde ich Flask ein wenig redundant. Ich hätte es natürlich lieber gesehen, wenn die werkzeug Entwickler mir bei der Integration eines werkzeug.Request Adapters geholfen hätten, statt noch ein Micro-Framework in die Welt zu setzen, aber ich kann die Motivation verstehen und werde mir wohl auch das eine oder andere von Flask zurück-abschauen ;). Besonders die Dokumentation ist gut gelungen. Da sollte ich mir ne Scheibe von ab schneiden.

Sinn macht Flask auf jeden Fall, besonders wenn man eh den Umgang mit werkzeug und Jinja2 gewohnt ist. Ich bin gespannt, was daraus wird.

@LOC:
Bottle hat die 1000 LOC Grenze schon lange gesprengt, allerdings ist der Code weiterhin sehr kompakt (keine unnötigen Abstraktionen oder Klassen-Ansammlungen). Ich bin glaube ich gerade bei ~1700 wobei viele Zeilen für Kommentare und die Server- und Template Adapter drauf gegangen sind.
Bottle: Micro Web Framework + Development Blog
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

ahojnnes hat geschrieben: Und genau hier denke ich, könnte Flask ansetzen, da es ja bereits auf Werkzeug und Jinja2 aufbaut (zwei wirklich sehr gute und vor allem mächtige Tools) und damit das >>Micro<< schon wegfällt.
Von werkzeug bekommt der flask-User ja eben quasi "nichts" mit, sondern es wird auf eine mögliche Art und Weise abstrahiert und benutzt. Dazu muss der Benutzer keine Ahnung von der werkzeug API haben.

Und jinja2 ist zwar mächtig, aber imho nicht schwieriger zu durchschauen oder zu erlernen als andere Template Sprachen.

Insofern denke ich nicht, dass das "Micro" wegfällt. mitsuhiko hat sein Verständnis von "Micro" ja auch schön auf der flask-HP dargestellt.

Ich persönlich fände es cool, wenn es eine Authentifizierungs- und Formular-Lösung dazu gäbe. Imho sind diese beiden Dinge auch bei kleinen Apps eine typische Anforderung und machen viel Code aus, für den man sich mehr Komfort wünschte. Allerdings hatten wie die Diskussion um eine gute WSGI-Authentication Lib ja bereits erst kürzlich geführt - mit wenig stimmigen Tools :-(

Für Formulare scheint ja WTForms sehr beliebt zu sein. Ich habe in dem Segment noch keine große Erfahrung und weiß daher auch nicht, ob eine weitere Abstraktion überhaupt sinnvoll sein könnte. Beim auf werkzeug aufsetzenden "glashammer" hat mich das viele "Durchschleifen" von externen Funktionen ein wenig gernervt. Wenn also keine sinnvolle Aggregation mehr möglich / sinnvoll ist, dann wäre eine solche Integration natürlich obsolet.
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Das von mir sollte auch keine Kritik an Flask sein, finde die Idee und Umsetzung echt klasse. Wollte damit eher einen Gedanken von mir mit ins Spiel bringen.

Form-Validation zu abstrahieren hätte meiner Meinung nach keinen Vorteil.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

ahojnnes hat geschrieben: Form-Validation zu abstrahieren hätte meiner Meinung nach keinen Vorteil.
Das hatte ich wohl übersehen :-)
Benutzeravatar
jbs
User
Beiträge: 953
Registriert: Mittwoch 24. Juni 2009, 13:13
Wohnort: Postdam

Sollte es nicht `message` statt `mesage` heißen? http://flask.pocoo.org/docs/patterns/wtforms/#the-forms
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

jbs hat geschrieben:Sollte es nicht `message` statt `mesage` heißen? http://flask.pocoo.org/docs/patterns/wtforms/#the-forms
Danke. Korrigiert.


Im uebrigen wenn was bei der Doku nicht verstaendlich ist, gleich melden. Flask ist mehr Doku als Code :)
TUFKAB – the user formerly known as blackbird
Tompee
User
Beiträge: 18
Registriert: Sonntag 7. Oktober 2007, 17:13

Hi,

irgendwie bekomme ich das mit Lighttpd-1.4.19 (Debian/Lenny) nicht zum laufen. Er lädt die ganze Zeit die Seite, aber es passiert nichts.

fastcgi.conf

Code: Alles auswählen

server.modules   += ( "mod_fastcgi" )
fastcgi.server = ("/main" => 
                        ("main" =>
                                (
                                "bin-path" => "/var/www/main/main.fcgi",
                                "socket" => "/tmp/main-fcgi.sock",
                                "check-local" => "disable"
                                )
                        )

)
main.py

Code: Alles auswählen

#!/usr/bin/python
from flask import Flask

app = Flask(__name__)

@app.route("/main")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()
main.fcgi:

Code: Alles auswählen

#!/usr/bin/python
from flup.server.fcgi import WSGIServer
from main import app

WSGIServer(app, bindAddress='/tmp/main-fcgi.sock').run()
Rechte:

Code: Alles auswählen

thomas@home:~$ ls -al /var/www/main/
insgesamt 16
drwxr-xr-x 2 thomas thomas 4096 21. Apr 19:40 .
drwxr-xr-x 3 root   root   4096 21. Apr 16:34 ..
-rwxr-xr-x 1 thomas thomas  137 21. Apr 19:36 main.fcgi
-rwxr-xr-x 1 thomas thomas  168 21. Apr 19:33 main.py
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Ich hab auch noch was gefunden:
http://flask.pocoo.org/docs/patterns/wtforms/#the-forms

Muss nicht das EqualsTo auf das Object password verweisen?

Code: Alles auswählen

from wtforms import Form, BooleanField, TextField, validators

class RegistrationForm(Form):
    username = TextField('Username', [validators.Length(min=4, max=25)])
    email = TextField('Email Address', [validators.Length(min=6, max=35)])
    password = PasswordField('New Password', [validators.Required()])
    # aktuell: EqualTo('confirm', ... -> muss doch auf password zeigen?
    confirm = PasswordField('Repeat Password', [validators.EqualTo(
        'password', message='Passwords must match')])
    accept_tos = BooleanField('I accept the TOS', [validators.Required()])
Und weiter unten im Macro aus _formhelpers.py fehlt das </li> im Original

Code: Alles auswählen

{% for error in field.errors %}<li>{{ error }}</li>{% endfor %}
Imho nur Kleinigkeiten - aber wenn man's schon entdeckt, kann man es ja auch melden.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Hyperion hat geschrieben:Muss nicht das EqualsTo auf das Object password verweisen?
Entweder das, oder man verschiebt den Validator. Das hab ich auch mal gemacht, ergibt eine besser platzierte Fehlermeldung.
Hyperion hat geschrieben:Und weiter unten im Macro aus _formhelpers.py fehlt das </li> im Original

Code: Alles auswählen

{% for error in field.errors %}<li>{{ error }}</li>{% endfor %}
Warum? HTML4 und HTML5 erfordern hier kein schliessendes Tag, und die Dos verwenden auch ueberall HTML und keine XHTML Syntax.

@jbs: fixed :)

Danke fuer die Hinweise, Docs wurden angepasst. Ansonsten bitte solche Sache im IRC Channel oder Bug Tracker melden, ich schau nur sehr selten in die Foren.
TUFKAB – the user formerly known as blackbird
Antworten