Since a couple of years my preferred programming language is Python - and therfore I'd like my web framework of choice to be also written in Python.
If you start looking around, the two propably most mentioned frameworks are Flask and Django. While Flask is a so called microframework (kept simple, build everything on your own) Django is a full fledged, feature rich software package with propably everything you'd ever want and some more. And of cause I don't forget to mention that async IO is currently a very hot topic.
Although I did some projects with Flask and Django, my framework of choice is Pyramid. It is more "bloated" than Flask but in contrast to Django it is completly unopinonated - you have to make up your own decisions on what to use and how to use it.
At first I just liked the overall approach and thorough documentation Pyramid provides but I fell in love with one concept: Resources.
If you start reading about the three frameworks, you'd encounter one thing they seemingly have all in common: matching a URL to a view callable. For an example: the response for a url like http://example.com/hello-world will be generated by a function or a class method and a request to http://example.com/goodbye propably by another one.
But Pyramid is slightly different on this. In Pyramid a URL is matched to a resource and the view to call is matched against this resource. So there is one level of indirection in the process – and if you don't want it it is abstraced away from you.
So what's the deal about this except for adding more complexity on the first look of it?
When I develop a web application, I prefer to have a "dumb" data model that only provide the most necessary data handling stuff. On the other side, I like to keep my view functions also as simple as possible - just handling the stuff needed for one specific task.
But there are some things that fall in between of theese that have to be put somewhere and where a resource is quite useful:
access to data model
A resource is the perfect place to retrive the data you work on from it's store. You don't have to query for the data in your view functions over and over again.
aggregate data from different sources
The data for one view might not be provided from a single data source like a database but may also come from web services, a work queue or something else. This relations propably don't "belong" into a pure data model class and not in a view function.
reuse of application logic
The best example for this in my opinion is access controll. Sure, you could attach this logic to your data model directly, but there are always cases, where you need to provide access controll to a functionality that is not tied to a data model. Pyramid offers an authorization system out of the box for resources if you provide an authentication mechanism.
traversal style routing
Although im using this method of matching a URL to a Resource most of the time in my Pyramid projects, I won't talk much about it here. Instead I urge you to read the Much Ado About Traversal chapter in the excellent Pyramid documentation. I propably couldn't describe it better.
There are a couple of more reasons you should be interested in the Pyramid framework, but I'll leave it to the resources for this write up. For me they are one of the most important features and (imho) the most underradet one.