Most Python frameworks, regardless, seem to score quite well-Flask, Turbogears, Bottle-in contrast to Django, which is to be expected as it doesn't try to be simple (it is, however, well documented and easy to learn).
I'm curious how the analysis in the blog post works. In languages like Python it's common to hide branches inside of data structure lookups like the following:
def f():
...
def g():
...
def h(x):
return {
True: f,
False: g}[not x]()The dict-as-a-switch expression is common to python, but it can be masked as the parent has shown in larger examples.
I have no idea how we could apply static analysis techniques to a construct like this. To be honest I tend to avoid this approach on readability grounds. It could be cleaned up with a dict subclass but I think inlining the dict call mechanics is simpler to read, even if it produces larger code, leads to repetition and couples you to this approach (which would be a strong consideration in the case of writing a library - where this type of code is most prevelant).
CC is useful for determining number of tests for complete branch/path coverage if you don't pull out the switch on dictionary tricks (among others).
And Django's complexity is really good in it's class. "Complex is better than complicated" - and Django tries hard not to be the latter :)
Look, I know that bare-bones Django looks simple, but in reality it isn't. You don't even have "bare-bones" unless you manually disable quite some functionality in settings.py. It's still good if you plan to grow your app. You can always turn the features back on and plug reusable apps with ease.
But for something as simple as getting JSON requests, hitting db and returning response I'd choose something else, some microframework and simplified ORM, for example Bottle and Storm[1]. I had a great success with using CorePost[2] on top of Twisted, but that's only if you can live without an ORM and like Twisted's brand of async.
Long story short: there is no need to employ Django for every little webservice. You can, of course, but you should think about why your using full-stack framework when something simpler, faster and smaller would do just as well.
[1] https://storm.canonical.com/ [2] https://github.com/jacek99/corepost
Most of the things aren't needed by most people, but it gets installed anyway.
EDIT: I am an idiot who clearly doesn't know much about Django and spake without prior research.
B) Django doesn't have its own cheeseshop. Django developers use PyPI and pip just like everyone else. (Maybe you're thinking of Crate.io, which is a PyPI mirror that happens to use Django in its implementation.)
As for complexity, I still think it's excessive. It's good to know the internals of a module/package/whatever, and django is really really complex, of which cyclomatic complexity quantifies I believe. I mean, if you have code that branches off everywhere, it'd be hard to follow the logic when inspecting the internals.
I'm curious: where did you read/see that?
One of the first few pages in the tutorial includes:
"Django apps are "pluggable": You can use an app in multiple projects, and you can distribute apps, because they don't have to be tied to a given Django installation."
and I guess it might be possible to mistake 'manage.py startapp ...' as some sort of internal packaging thing if you don't look too deeply.
To answer your question: I am an idiot and I didn't know much about Django. I did once find djangopackages or something like that and simply jumped to the conclusion. Big and Unwieldly is the brand perception I had.
And catering to 'every single edge case' actually seems to contradict the philosophy I've observed on the django-developers list.