I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a community as Django, most developers would need to see major gains in one or more areas; performance, docs, community, coding efficiency, etc.
Pyramid doesn't offer these gains. It only makes promises about maintainability, which are hard to verify, unless you personally know somebody that you trust as a skilled developer, and who has worked on a sufficiently large enough project in Pyramid to make such claims... it's easy to see how this creates a hole that Pyramid has to dig itself out of.
Also, Pyramid still talks about "supporting your decisions", like Jinja2, etc., as if that's a problem people are still dealing with. Django supports Jinja2 even in the admin now, let alone being able to use whatever you want elsewhere. As a side note, I don't see many Python developers wanting to use anything other than Django templates (for simplicity and separation of concerns) or Jinja2 (for speed and flexibility) these days.
If the argument, in response to the aforementioned difficulty in verifying claims about maintainability, is "well, it's up to you; Pyramid stays out of the way", then the immediate response is that you're better off using Flask or Falcon; the former if you need third-party tools, and the latter if you need maximum raw speed, but still want Python. Both of those frameworks will drastically outperform Pyramid and stay out of your way.
IOW, I don't think Pyramid fills any reasonably sized and easily understood market gap.
1. https://www.techempower.com/benchmarks/#section=data-r13&hw=...
I'm curious about the result since it didn't matched my experience. So I proceed to take a look at the source code for both Pyramid's[1] and Django's[2] benchmarks. From the look of it, I feel like there are too much difference in implementation to call this a realistic comparison.
From a quick glance, Django's benchmark seems to contain a little bit of micro-optimization and is rendering JSON response directly with uJSON[3] (which looks to be a lot faster than native JSON module)[4], while Pyramid's benchmark did not seems to go through any optimizations and is returning a list of SQLAlchemy objects that get passed into a custom renderer[5]¹ and render using native JSON module.
So I don't think it's entirely fair to say Pyramid is slow in a real world scenario based on this benchmark alone.
[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...
[2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...
[3]: https://pypi.python.org/pypi/ujson
[4]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j...
[5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/c8a5...
¹ Using pyramid.renderers.JSON here probably make more sense, but to match Django's implementation, one can wrap a serialized JSON into `Response` object.
Django has grown up a lot in the last several years. It used to be really hard to use a different templating language, and I personally really dislike Django's templating language. That was the biggest turn off for me every time I looked into Django. If it had been pluggable earlier, this probably would've changed the calculation for me.
I've always thought of Pyramid as the ideal framework, conceptually. It feels like you're writing Python, not Pyramid, which is GREAT. Pyramid only shows up when you say "OK, I have my Python stuff; I need to make this show up in the web browser now." It is entirely unobtrusive. All frameworks should strive for that.
Unfortunately, the vast majority of frameworks take the opposite approach. Django at least used to be an example of that by forcing DTL (is this the abbreviation for "Django Templating Language"?) down everyone's throat, among other things.
I've also been very impressed by Chris McDonough and the rest of the Pyramid team. They're extremely helpful in IRC, they keep up the great work even after spending years as a small/niche framework, and their code is very clean and well-tested, not obnoxious or overcomplicated. It's a tight, consistent framework that stays out of the way and is just there to serve the developer, not to force him/her to comply. It is so everything a framework should be and so everything most frameworks aren't that I can't help but love it.
I haven't done a major Python-based web project for many years (have one in progress, porting a Rails-based site to a Mezzanine-based site, but work on it only rarely), so I'm sure some of this is outdated.
What makes Pyramid better for you than e.g., Falcon?
From your comment, it sounds like a lot of the value you've gleaned from Pyramid is based on the framework staying out of your way, so why not use something 5x faster that does the same thing? Does Pyramid provide some unmatched abstractions? (I'm coming from a position of no true experience in Pyramid)
You have event system, security abstraction, all kinds of overloading helpers for views and internal machinery that falcon doesn't seem to provide at least from my cursory look. Compare the size of documentation and configuration options between both projects.
Also looking at this http://klen.github.io/py-frameworks-bench/ the 5x better speed of falcon seems to be completly made up or occur in some very specific situation. More realisticly it looks like falcon can be 30% faster in some scenarios not involving storage - but for the price of giving you less options.
Which probably means that if you use any kind of storage the difference between those two can be ignored.
And the developers seem to think this is totally ok.
In my experience, anything that doesn't have a commitment to at least fixing security issues for ~5 years, isn't a good choice for business. Businesses don't want to tie their internal development and release cadence to an external development team with less than 3 year cycles, ideally 5+.
I've seen it time and again over dozens of companies. There is no time to qualify apps for new major/minor releases. Anything that doesn't have a LTS release story is just not something I can feel good about deploying in my business.
To be clear the core maintainer-ship of pyramid is about 2-3 people. We would love more contributors to the core codebase, but with that level of commitment we're obviously not able to provide a comparable level of support to a project with more contributors. This is the nature of open source and it is the rare exception to the rule to find packages / projects that have grown to be able to offer such a level of support.
(Aside: mmerickel is the developer I was talking to in Freenode)
Honestly, I didn't know that Pyramid had such a small amount of manpower behind it. It presents itself and has a reputation in the Python community, at least in my experience, of a bigger project.
But, as far as not being able to commit to security releases for old versions: it's obviously a choice in where to spend the available resources, not one of the size of those resources. Choosing new development over providing critical fixes of older releases is a choice, it's just one I need to understand before I commit to using a component. I understand why one would make either of those choices, I just need to know which one has been selected. It is great for people who want to choose forward development focus, I'm just not one of them.
I believe it's better for them to focus on what they know they can do day in and day out regardless of the circumstances and let companies make the decisions that make sense to them.
In a world where the hardware is written off by the business in 3 years though and websites age out at 3 years and car manufacturers are increasingly trying to hit a 3 year model revision mark it seems to me it's not too much to ask that companies investing hundreds of thousands in an application using Django or Pyramid also invest in maintaining it and keeping it modern or perhaps their existing business model needs additional revision too.
Just a thought as the least informed member of HN.
- request/response (webob) gets its own updates.
- templates get their own updates.
- sqlalchemy gets its own updates Etc.
You WILL get security fixes for most of your application even without upgrading the framework itself (the attack surface for pylons/pyramid itself is smaller than monolith).
By being on a lower version you don't really miss much - the API's are very stable. And 99% of time you can update pyramid version itself without risking application breakage (the chance of it is probably a lot lower than with monolithic framework).
I know about very heavy websites that are still using pylons(precursor to pyramid) in production without issues (8 years now).
[0] http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover
Use Pyrapid Like a Pro
This makes it sound like an advanced toy rather than a bullet-proof work of engineering you can rely on. Which is really a pity, because Pyramid _is_ a framework you can rely on.
It's a shame, because I've wanted to try Pyramid since I watched their talk at PyCon 2011, but the branding (including the new 99 Designs looking logo / theme) has always made me think, "This will never really take off."
Still my go-to framework though. The websauna framework linked above might be something I have to try.
As I build more and more side projects I find myself wishing pyramid were just a bit more opinionated so I could get the basics up and running a tad faster. At this point I mostly cut up old projects and port them to each next one, heh
The theme is one of the included ones, Ribbon.
They say "Start small, finish big", and push the fact that Pyramid scales from a single file codebase, up to many files. This is something that I just haven't seen in practice.
A Django project requires quite a few files, so it's never a great answer when the total amount of business logic is <100, or maybe even <1000 lines of code. However, a 10k line Django site and a 100k line Django site basically look the same in my experience, and that is hugely valuable.
The biggest red flag from Pyramid for me is their point: "Use Pyramid as a "framework framework" to craft your own special-purpose, domain-specific web system".
In my experience, this means that every project is a special snowflake of a project that works in a very different way to other projects. With Django you have a tried and tested architecture, with Flask and Pyramid, it often seems that you have to create your own architecture in some ways, and that results in each project being really quite different.
Offers Django feature parity with best of breed components.
If you have any questions please pop into the chat http://gitter.im/websauna/websauna