Chris McDonough

What you say is not always true either.

I do Python mostly. Django? Fine. It has an excellent auth system out of the box. But that kind of auth system isn't very flexible either. Now I barely do Django development today so please excuse me behind any insane changes.

Flask and Pyramid world? Custom auth to me. They both have community modules for auth stuff, but do I really like them? I am not the kind of guy just pip install random "useful" package these days. Let's give another example. A year or two ago I tried to do social auth in some of my django and flask apps. Maybe I was dumb but using that social-auth library took me a while to get some of login working. Plus, the code was messy and buggy. In the end, I said screw that and implemented all of the custom login myself, just reading the official doc from twitter and facebook. That also took me a while but I knew the whole implementation inside-out. If I don't trust my own implement because it is insecure, then I must spend the same amount of time inspecting other people's custom modules.

The truth is, generic auth system is hard and is not flexible. In fact, too flexible can be a bad thing: http://plope.com/pyramid_auth_design_api_postmortem

I like customized auth system based on the api provided by the framework - that' what makes Pyramid powerful to me. Sometimes your community auth module can have limitation that you probably have to hack around.

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-technology-shootout-%E2%80%93-round-4-pyramid-vs-django-vs-tg-vs-rails-2-3/), so the optimizations we're doing are working, AFAICT.

There are lots of people that agree with you: http://www.plope.com/Members/chrism/pythonic

I preferred what Ian Bicking wrote in response: http://blog.ianbicking.org/unzen-of-unpython.html

One thing I like about the Django community is that part of Djangocon specifically features critics who are invited to criticize Django or some aspect of it, for example:

"Why Django Sucks and how we can fix it"
http://blip.tv/djangocon/why-django-sucks-and-how-we-can-fix-it-4131303

Flasky Goodness (or Why Django Sucks?)
http://reinout.vanrees.org/weblog/2012/06/06/flask-django-sucks.html

That's much better and productive than circling the wagons and letting personal insults fly.

Well that's cause the Pyramid Auth API is admitted by the authors to be overly complex. They did a post mortem here and you can read about some of the mistakes they made when designing the API: http://plope.com/pyramid_auth_design_api_postmortem

The most relevant line to take away from their post mortem is this: "Unfortunately, when designing a framework, you get exactly one shot at creating "the right" API. In this case, we didn't."

So even with a decoupled API, if the design doesn't fit your needs or is too cumbersome to use, you will still need to find a third party solution or hack the core code. Both of which, as mentioned by others, are possible in Django.