[aidos]

I looked into Falcon a while back - looked interesting but it wasn't immediately obvious what I would get over Flask (if nothing else, there's a tonne of Flask docs out there these days).

In all my research over the years Pyramid is the framework that looks the most interesting. The docs are amazing (I more or less read them cover to cover, even though I haven't tried the framework) and the whole thing seems very well thought out.

I'd love any insights from people who have worked with it.

[goo]

I've worked on one project with Pyramid extensively, and I've been relatively pleased. It gives you a lot of flexibility, which can be good and bad. There is useful code that helps you unit test your app, and it is not a particularly opinionated framework. That being said, the number of options that pyramids allows can be a little overwhelming -- it gets a grade 'C-" when held up to the zen of python's line: "There should be one-- and preferably only one --obvious way to do it." When held up to "Although practicality beats purity.", as well as most of the rest of the pythonic ideals, Pyramids gets a solid A.

Personally, I'm excited to explore flask more, since it seems to put the ball entirely in your court. I like the concept behind flask a lot -- for some projects I'm willing to sacrifice additional framework features in exchange for a more careful understanding of everything I am adding to my app.

[mmerickel]

Yeah I mean it's hard to digest comments like "it's not a particularly opinionated framework" against things like "put the ball entirely in your court". They seem to be saying the same thing except you have a different perception of each when you say it.

The problem as I see it is that Pyramid has a lot of extra interfaces and support for things in the core by default (and some concepts that are completely missing from most frameworks like context). So much is there that it's easy to lose sight of how little is actually required. Fundamentally you can write Pyramid apps in 10 lines of code exactly as you would with Flask but that's less interesting for bigger apps and so the docs focus on all the extra features.

I mean if you take the example at the top of http://docs.pylonsproject.org/projects/pyramid/en/latest/ and add in the pyramid_jinja2 library via config.include('pyramid_jinja2') then you basically have views and jinja2 rendering fully baked.

As in the previous example if you get right down to it Pyramid doesn't even have a templating engine! Flask comes with jinja2 built-in! So scaling DOWN to APIs where this is not necessary is an interesting thing..

[goo]

It's a matter of conceptual load, not about the actual capabilities. By "putting the ball in your court" I mean to say that flask adds an insignificant amount of conceptual load, and the overall difficulty to read and understand your app will be based on what you decide to add beyond flask.

By saying "it's not a particularly opinionated framework", I mean to say that it allows you to add, easily, whatever you want to it. However, there is a fair amount of conceptual load in doing so. The difference between a flask app and a pyramid app with pyramid jinja2 built in is that one of them takes about 20 seconds to understand.

Don't get me wrong -- I think pyramid is fantastic. But it it is disingenuous to suggest that there are not differences in complexity between the two frameworks.

[mayhew]

You could always just use Werkzeug directly if you're just building an API.

[mmerickel]

"just building an API" does not mean you need something more lightweight. It means you have different requirements from a standard full stack web application. You are not dealing with cookies, forms or template rendering but you are still dealing with lots of other problems including authentication, authorization, headers, etc. Pyramid is the ONLY framework I've ever seen that comes with builtin support for dispatching to a view function based on more than just a request method (GET vs POST). In Pyramid GET vs POST is equivalent to any other request property including accept headers, cookies, query strings, etc. Any of these can dictate a different callable. See http://blog.delaguardia.com.mx/pyramid-view-configuration-le... for some examples.

[andrewstuart]

That's really useful.

[mmerickel]

Well as one of the primary maintainers of Pyramid I'll just say that it's laughable to me all the comparisons to Django as it's much more similar to Flask. The main difference is that it comes with several more "pay only for what you eat" standardized interfaces that you can use to pull things together. It's declarative security concepts are fantastic and completely missing from most other frameworks as well which choose to punt this part to (usually) half-baked addon libraries built to serve one specific use-case.

[andrewstuart]

>> it wasn't immediately obvious what I would get over Flask

Falcon gives you less than Flask, not more.

For me the big thing is that Falcon has none of the stuff needed for building web apps. Flask has all that stuff cause it was built when back end servers also built the HTML pages. There's alot of stuff associated with that functionality in Flask that is not there in Falcon. It makes it much cleaner.