Il n'a pas plus de fonctionnalités que Flask, il en a même moins (pas de template, pas de session côté serveur...), sa particularité est d'être pensé dès le départ pour être flexible et extensible, le lien "Defending Pyramid's Design" explique bien comment et pourquoi ces notions sont mises en place.
Quelques détails : le système de route est plus explicite et robuste, on peut inclure une application dans une autre sans risquer de conflit. Pyramid n'utilise pas threadlocal, le passage de request est toujours explicite, cela facilite les tests et l'inclusion d'applications. Les Tweens remplacent les middlewares, ils bénéficient ainsi du "contexte". Il y a quantité de petits hooks et paramètres pour obtenir un comportement personnalisé. Compatible py3. Bref on voit dans les petits détails que tout a été pensé pour que l'application puisse évoluer sans limite et de manière robuste sans être pour autant pénalisée au début. L'utilisation basique reste quasi identique à Flask. On pourrait très facilement imaginer construire Flask ou Django sur Pyramid. Il faudrait d'ailleurs plutôt les comparer à https://github.com/ptahproject/ptah
Etant donné la quantité de petits détails techniques qui font la différence, il faut se plonger dedans pour en mesurer les avantages. J'ai été convaincu quand j'ai essayé de migrer de mon framework perso, qui commence à sentir le renfermé, vers un framework plus ouvert. J'ai pu l'adapter progressivement (et surtout de manière très propre) vers Pyramid sans avoir à changer une ligne de mes applications (dont certaines ont plus de dix ans) ! Ce qui m'assure l'inverse, à savoir que demain un Pyramid 2 ne m'obligera pas à changer mes applications, problème majeur des frameworks.
Pour répondre à ta question de noob, c'est l'éternelle question que l'on retrouve dans la "philosophie unix", est-ce que tu veux continuer à rester noob ou pas ;-) ?
[^] # Re: Pyramid vs ..
Posté par wilk (site web personnel, Mastodon) . En réponse à la dépêche Publication de Pyramid 1.5. Évalué à 6.
Une vidéo de l'auteur de Pyramid sur la différence avec django qui pourra aiguiller
http://pyvideo.org/video/1407/about-django-from-the-pyramid-guy
Il n'a pas plus de fonctionnalités que Flask, il en a même moins (pas de template, pas de session côté serveur...), sa particularité est d'être pensé dès le départ pour être flexible et extensible, le lien "Defending Pyramid's Design" explique bien comment et pourquoi ces notions sont mises en place.
Quelques détails : le système de route est plus explicite et robuste, on peut inclure une application dans une autre sans risquer de conflit. Pyramid n'utilise pas threadlocal, le passage de request est toujours explicite, cela facilite les tests et l'inclusion d'applications. Les Tweens remplacent les middlewares, ils bénéficient ainsi du "contexte". Il y a quantité de petits hooks et paramètres pour obtenir un comportement personnalisé. Compatible py3. Bref on voit dans les petits détails que tout a été pensé pour que l'application puisse évoluer sans limite et de manière robuste sans être pour autant pénalisée au début. L'utilisation basique reste quasi identique à Flask. On pourrait très facilement imaginer construire Flask ou Django sur Pyramid. Il faudrait d'ailleurs plutôt les comparer à
https://github.com/ptahproject/ptah
Etant donné la quantité de petits détails techniques qui font la différence, il faut se plonger dedans pour en mesurer les avantages. J'ai été convaincu quand j'ai essayé de migrer de mon framework perso, qui commence à sentir le renfermé, vers un framework plus ouvert. J'ai pu l'adapter progressivement (et surtout de manière très propre) vers Pyramid sans avoir à changer une ligne de mes applications (dont certaines ont plus de dix ans) ! Ce qui m'assure l'inverse, à savoir que demain un Pyramid 2 ne m'obligera pas à changer mes applications, problème majeur des frameworks.
Pour répondre à ta question de noob, c'est l'éternelle question que l'on retrouve dans la "philosophie unix", est-ce que tu veux continuer à rester noob ou pas ;-) ?