cherrypy vs fiole / werkzeug

Question

Je veux écrire un Python "de l'information server":

• Différents types d'informations seront affichées: tableaux de données, documents, etc. Certains est dynamique et statique. J'aimerais utilisation de modèles HTML, et je suis déjà à l'aide de jinja2 (avec pygments).
• Il se peut également que certains "live update" pages donc je voudrais utiliser AJAX et jQuery peut-être.
• Je tiens à déployer ce, sans avoir à installer et configurer un serveur HTTP (par exemple Apache). La circulation sera assez faible. Mais j'aimerais une efficace Python serveur.

Les deux solutions que j'ai à l'esprit sont Cherrypy ou Flacon (et Werkzeug). (Ceux-ci seront utilisés avec jinja2, jQuery, SQLite, SQL-l'Alchimie?) Cherrypy a été autour pendant un moment et semble tout à fait mature et ressemble à une efficace mise en œuvre de serveur et toutes les fonctionnalités que je voulais. Flacon est plus récent, mais un aspect plus poli, et je suis impressionné par le travail de Pocoo.

Quelqu'un aurait-il l'expérience d'avoir travaillé avec les deux systèmes? Quelles sont les limites? Comment ils se comparent (caractéristiques, la documentation, le support, de bogues, de la vitesse).

Est Werkzeug efficace d'un serveur? J'ai lu que Cherrypy est à peu près aussi efficace qu'un serveur que vous pourriez écrire en Python. Est Werkzeug rapide/rebust assez pour un petit site?

Veuillez ne pas répondre par "oui l'homme, le Flacon est cool, vous devez l'utiliser." Qui ne me dit rien au sujet de votre raisonnement ou l'expérience et me fait penser que vous n'avez pas vraiment du tout.

Answer 1

Je n'ai pas d'expérience avec Flacon mais je pense que j'ai assez de l'exposition à CherryPy faire une observation.

Ce que j'aime à propos de CherryPy:

1. De la simplicité. Contrôleur objet d'arbres plus ou moins égale à la façon dont vous définissez vos Url.
2. La flexibilité. Dans le cas où vous n'aimez pas la façon dont les Url sont définis par défaut, vous pouvez utiliser des itinéraires ou des méthodes pour exposer votre URL gestionnaires, qui sont tout aussi faciles.
3. Outils. CherryPy n'est pas que religieuse sur WSGI, si c'est 100% compatible avec le WSGI spec, l'approche recommandée consiste à utiliser des Outils. Ils sont simples à réaliser et à utiliser, et la façon dont ils sont connectés à la demande est beaucoup plus efficace que WSGI, qui, en général, une demande doit passer par si oui ou non ce WSGI middleware est pertinent. (Sauf si vous utilisez un cadre où chaque gestionnaire d'URL est une application WSGI, mais câblage WSGI apps sont toujours ennuyeux). Il ya BEAUCOUP d'entre eux installés par défaut dans la plupart des cas d'utilisation que vous pouvez penser.
4. Les Plugins. Pour les sujets transversaux, moteur de plugins sont un beaucoup plus précis, bien définis, et de la manière appropriée de traiter avec eux, par opposition à une application WSGI, ce qui est généralement le marteau que les gens utilisent pour marteau dans chaque vis de ces jours.
5. Facile fragments de réponses. Vous venez de rendement d'une chaîne de caractères dans le contrôleur et c'est tout. Très utile pour le retour des documents de grande taille en pièces.
6. Complet de demande et de réponse des objets. WebOb et CherryPy sont sur les 2 seuls les cadres qui ont comparativement complète des implémentations d'entre eux, mais je serais encore choisir CherryPy pour la dernière raison:
7. Zéro dépendance à d'autres paquets. Vous n'apportez pas dans une douzaine d'autres bibliothèques, juste pour lancer un serveur. Vous venez de easy_install ou pip install cherrypy et c'est tout.

Oh, et ai-je mentionné qu'il est très RAPIDE et très STABLE?

Mise à jour: CherryPy est de la pure Python WSGI serveur web est maintenant extrait dans son propre projet appel Cheroot.

Answer 2

J'ai travaillé avec les deux depuis quelques mois, à l'aide de CherryPy que le serveur et Flacon en tant que cadre-et je n'ai eu aucun problème du tout. (C'est un outil interne, donc un trafic très faible, très semblable à la vôtre par le son des choses.)

Résumé de mon expérience: en cours d'Exécution Fiole avec le serveur de développement n'était pas stable, tournant Flacon avec CherryPy que le serveur a été solide comme le roc.

Je n'ai pas passé beaucoup de temps à développer avec CherryPy en tant que cadre, je ne peux donc pas commenter vs Flacon -- mais en utilisant les deux ensemble a été une véritable victoire.

Answer 3

Pourquoi êtes-vous en comparant Cherrypy et Flacon (Werkzeug) comme serveur WSGI?

Cherrypy a intégré dans le serveur wsgi pour le niveau de la production.

Werkzeug basé sur wsgiref de niveau de développement.

Vous pouvez vous servir de votre ballon d'application par Cherrypy http://flask.pocoo.org/snippets/24/ ou http://werkzeug.pocoo.org/docs/deployment/proxying/#creating-a-py-server

Si vous avez prévu d'utiliser Jinja2 avec SqlAlchemy le Flacon est le meilleur choix:

• Déjà pris en charge Jinja2

• Nice extension de SqlAlchemy soutien http://packages.python.org/Flask-SQLAlchemy

Answer 4

Quand j'étais à la recherche dans ce que j'ai lu cette question. Évidemment, Alex Martelli détient beaucoup de poids, étant une plus-jusqu'à Google. Il a dit:

Django pouvoirs, plus de 80% de Python-codé sites web, selon certains les estimations. Alors que c'est certainement la façon plus puissant que vous avez besoin, il est quelque chose à dire pour aller juste avec le flux.

À l'autre extrême, nu Werkzeug (avec WSGI) est tout à fait utilisable... et Flacon n'est pas beaucoup plus que cela (plus Jinja2, mais c'est tout à fait OK pour création de modèles, après tout). Moi, j'irais pour c'.

Maintenant, je n'essaie pas de démontrer mes compétences en programmation, comme l'original interlocuteur. Je veux un site web, avec le minimum de tracas. J'ai joué avec Cherrypy, Fiole, et passé par le Django tutoriel. Je pense que je vais aller avec Alex le premier paragraphe, plutôt que la deuxième. Je n'ai pas toute la lof du web, l'expérience de la programmation, et la jambe jusqu'que Django vous donne, avec toutes les docs, les plugins et le soutien probablement la meilleure option pour moi.

La raison pourquoi j'ai considéré Cherrypy et Flacon pour éviter de la courbe d'apprentissage d'une pile complète de l'approche, à l'instar de Django. Mais, après avoir parcouru le tutoriel, je pense que c'est venu un long chemin depuis la dernière fois que je l'ai regardé (< v1.0).

Merci pour tous les conseils.

Answer 5

Le serveur Werkzeug est conçu pour le développement, il est déconseillé de l'utiliser. Cela dit, pourquoi n'utilisez-vous pas les deux, CherryPy en tant que serveur Flask / Werkzeug pour l'application?