Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/na... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django).

(Other examples where the other two's solution feel rather lackluster to me include middleware vs. view derivers, view predicates, the routing system and the security area)

I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django.

Any areas that Pyramid doesn't do well at?

It has nothing like the django admin and no forms handling is built into it. Creating a project from scratch is a bit cumbersome (like flask), but good cookiecutters exist (e.g. the pyramid-sqlalchemy one).

Wow, Pyramid even seems to pitch itself as the "Goldilocks Solution"! OK, will give it a try.

Maybe it's because I'm used to Rails, but there is really little magic in Django. One is even free to structure the code as one likes. Almost no mandatory directory structure. It's a beefier Flask but still straightforward. If I may come up with a criticism, there are too many complications that slow down development compared to Rails.