chrism

This is also a nice one: http://www.serverzen.net/2010/11/8/getting-started-with-pyra...

Since you believe this using C to reduce function call overhead is cheating, here's Pyramid 1.0a9 profiling output with the "zope.interface" C optimizations disabled (same methodology and code used to test the C-optimized variant):

http://plope.com/static/noncoptimized.txt

That's 27 lines of profiler output, which, if you're keeping score, is still fewer lines than any other framework tested. We're not really hiding anything here.

The comparisons to other frameworks are largely a gimmick to drive traffic and comments, granted. In the real world, these numbers shouldn't make the difference about whether you choose one framework or another.

However, there are actual speedups to be had by other Python web frameworks if they'd consider using some of the techniques outlined in the blog post. In the real world, actual benchmarks seem to have Pyramid bottlenecked by the WSGI server (see for example http://blog.curiasolutions.com/2010/11/the-great-web-technol...), so the optimizations we're doing are working, AFAICT.

Python function calls have overhead. Avoiding them is a common optimization technique.

Pyramid 1.0 final will be out before PyCon US (~ 2 months from now).

However, it bears saying that, so far, no alpha release of Pyramid has been bw incompat with the last in any way. As a result, I wouldn't be scared off much by "alpha" in its version designator, at least as an evaluator. The code in Pyramid has existed for almost 2 years now. Every release has 100% statement coverage via unit tests. An alpha of Pyramid is arguably much more stable than many "final" releases of other web frameworks.

Considering the three principals of three (previously-separate) systems are congregating around one (Pyramid), doesn't it make your decision a little easier rather than harder?

"No clear visual distinction between links to glossary terms": yep, fixed a while back. Glossary terms are now green, other links are blue.

Traversal explaining: we're working on it (really). The docs have been rearranged and massaged a good bit, and they're being futher (professionally) edited now.

Flexibility: the best I can do about that without betraying the goals of the project is http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyra... . I'm also working on a cookbook here: https://github.com/Pylons/pyramid_cookbook which should provide the tl;dr'ers with a way to perform common tasks without needing to read didactic explanations.

A defense: http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyra...

As the author, I'm interested in improving the Pyramid docs. Can you elaborate on your issues with them? Did you notice the tutorials at http://docs.pylonshq.com/pyramid/dev/index.html#tutorials (lots of people seem to miss them).