My Pylons (Pyramid) Notes

I had this idea that I would make a new site using Pylons as the framework. So I headed over to www.pylonsproject.org and I see that its no longer Pylons its Pyramid. Ok so be it.

Well download the doc and I find out the Pyramid guy doesn’t seem to like MVC for web development, eh?:

You Say Pyramid is MVC, But Where’s The Controller?
The Pyramid authors believe that the MVC pattern just doesn’t really fit the web very well. In a
Pyramid application, there is a resource tree, which represents the site structure, and views, which
tend to present the data stored in the resource tree and a user-defined “domain model”. However,
no facility provided by the framework actually necessarily maps to the concept of a “controller”
or “model”. So if you had to give it some acronym, I guess you’d say Pyramid is actually an
“RV” framework rather than an “MVC” framework. “MVC”, however, is close enough as a general
classification moniker for purposes of comparison with other web frameworks.

So right off the bat i got a bad taste as I personally *LOVE* MVC and I cannot understand why anyone with any real experience in using it would say otherwise in a decent size web application.

At any rate I start to get into Pylons, er excuse me Pyramid, kudos to that team for some great documentation. After reading, perhaps browsing is better stated?, the 700+ page PDF I decided its not really the framework I would use in any production environment.

Why? Well several things struck me as very odd;
1. The author of a web framework doesn’t like MVC – yea really that’s a big deal for me.
2. Since its not using “controllers” per say its a bit confusing the “routing” – again a hangup for me with my MVC heavy background.
3. Too many choices. Yes really this is a complaint. I say this as the docs point out 3 ways to do something good, but really nothing done well. I rather take an opinionated stance and show how to do what you think is best – well.
4. Seems either over enginered or just complicated by the many config files; setup.cfg, *.ini, setup.py.
5. Static asset routing seems really odd. I guess I expect to just set a route to a path and that automatically serve requests for objects in that view. Meaning I would expect “/favicon.ico” is served via a route setup pointing “/” to a folder – not having to setup a static route for every file.

Its an interesting framework, just not for me. I kept reading the documentation thinking – this would be so much easier and cleanly implemented in MVC.

Ah well onto CherryPy.