He mentioned that he might open source it, but hasn't done so yet. I encourage people to put some pressure on him to do this =)!
http://bret.appspot.com/entry/experimenting-google-app-engin...
EDIT: I'm not sure who wrote the framework, so I was wrong to say that Bret wrote it. In any case, it was written by FriendFeed developers.
TurboGears, web.py, and Pylons failed the test.
The Python community would benefit from more people switching to Django. It does have the approval of the BDFL, after all.
I kind of doubt that though.
That makes it a non-starter for us (for now).
Of course, you can use whatever other libraries you want in your own code, but at the point where you are not using Django's ORM and you have left its lame template system for something like mako (or maybe genshi, especially if you are generating XML), then what is Django really giving you?
For example:
In Rails, you can say
Article.find(:all, :include => :comments)
for a in Article.objects.all():
a.comments #hits the database again! argh!
Forms handling and validation is another sore spot. Some validation happens in the model, some in the form, ModelForms does somethings, but not others, editing related objects is a mess. In some ways it's shocking that it's such a mess considering how awesome the admin interface is. However, I always find myself manually dealing with forms to a point that's just annoying.
The lack of a true "if" in the templates. It's just limiting in a way that I don't find useful and I find that it makes my code less clear by nesting things in weird ways to get the desired effect.
Stagnation. Django is awesome, but sometimes it takes forever for small things to go anywhere because there's a genuine hesitance in the community to "dictators". By dictators, I mean personalities like DHH who say, "well, this way works and is elegant and we're going to go with it." On the one hand, it's what makes Django really attractive as a community. Rails attracts the know-it-all personalities. Maybe DHH and Zed do know it all, but most Rails programmers definitely don't. People in the Django community are really helpful, respectful of other's knowledge, and love learning from each other. However, it also means that even tiny features must be rehashed over and over, filed in triplicate, lost, found, stamped, checked by a committee of 8, rewritten from scratch, named new-X or X-refactor, break API compatibility, and finally get into SVN. Ok, most of that was a joke, but there are lots of little areas where it just seems like Rails is willing to move on something based on the general mood where Django wants a more formal assessment and wait period before deciding whether something is ok to be in or not. And for all people complain about DHH's one-way-to-do-it mentality and Django's more open structure, Rails isn't so closed and Django not so open.
Django's big selling points (for me) are that there's a ton of python out there that's beautiful, reliable code and the admin interface that allows you to deal with content neatly and easily. Clearly there are other selling points like MVC and ORM and whatnot, but there are many frameworks that have that. Django is a lot easier to understand (at least for me) in its implementation. Django's documentation is top notch which is amazing compared to other projects, but Rails is catching up with their guides and screencasts. Django also tends to document things like their file backend hooks better which makes creating plugin-type things easier, but again Rails (with the help of the Merb team) is going to be a ton better in this area.
You won't go wrong with Django. The only fatal flaw is really the first one and it's just unacceptable at this point in time. But it's a great set of code with a wonderful community. I don't think there's another framework I'd prefer. Maybe Rails, but nothing else.
Article.objects.all().extra(select={'comment_count': 'SELECT count(*) FROM blog_comment WHERE blog_comment.article_id = blog_article.id'})
I've talked to Malcom about it (who wrote the QuerySet Refactor branch - or at least a substantial portion) and it's a known deficiency. Basically, the issue is two-fold. First, no one has stepped up to write the code that would make select_related() work in that fashion. Second, people want the implementation to disallow certain bad situations.
The first part is self-explanatory: select_related() should be enhanced to support that, but someone needs to write the code. The second part isn't as much, but it's more interesting.
Let's say you execute this query:
SELECT * FROM articles LEFT OUTER JOIN comments ON comments.article_id = articles.id
Now let's say we have this:
SELECT * FROM articles LEFT OUTER JOIN comments ON comments.article_id = articles.id LEFT OUTER JOIN votes ON votes.article_id = articles.id
So, the Django folk aren't into letting you just hang yourself out to dry like that. There have been proposals to limit it in ways that wouldn't let you do that, but it's really just something genuinely missing and there isn't a way to do it other than running looped queries or doing something ugly.
extra() doesn't do the same thing as select_related(). I'm not saying that doing ORM over multi-valued relationships is easy or that you can't execute queries that are really bad doing them, but it still means that there isn't support for a pretty basic function.
You can also reap the great benefits of the ZODB very easily with Grok alone. Grok is very easy to learn, and was designed by people that really know what they are doing with regard to Python web app development.
Still, Zope3 requires a bit more mental overhead due to the infrastructure it contains meant for handling extremely complex application domains and use cases with relative ease. For example, none of the other frameworks has an authentication and authorization implementation that is anywhere near Zope's in terms of pluggability and flexibility. Very useful if you need to build an intranet app that gathers user login credentials from several systems, and their permissions from some other system, but almost entirely useless if you're building a Web 2.0 app where content is strongly owned by an individual user who only needs to grant viewing permissions to other users.
At least, until you want to add group permissions, role-based security rules, or need to alter permissions based on workflow state, and be reasonably sure that your solution is actually secure.
The Zope universe is full of reusable optional libraries that solve problems that are this complex, and the framework itself has to have some additional complexity in order for it all to plug together in a reasonable way. This extra level of complexity is represented in the Zope Component Architecture (primarily zope.interface and zope.component). To handle the 'plugging together' part as configuration rather than code, we also have an XML-based configuration language called ZCML.
To people who think that they don't need that complexity because their problems are simple, Zope seems like overkill. But then they end up re-inventing wheels such as access-control-lists, and not necessarily doing it well at all.
First, what Django can learn from Zope: http://www.youtube.com/watch?v=fipFKyW2FA4
Next, what Zope did wrong and how it is being fixed: http://www.youtube.com/watch?v=iAsa1P9Dvd0
Its HTTP implementation is top notch, its tool system is a great way to write custom modules, it has excellent WSGI support, and it's just about the fastest HTTP server in Python that takes a thread-based concurrency approach.
I was the first engineer hired on a team that built an online survey-research company. We started using twisted/nevow, but eventually moved to an in-house web framework on written on CherryPy. Lots of tools have come and gone (mostly, we've rewritten components we found lacking) but CherryPy has never let us down. We even ended up hiring a large portion of the CherryPy team.
Our experiences with it were positive enough that I'm building a startup right now on a similar CherryPy-based stack (at least partially--there's also a bit of Erlang involved for the high-concurrency stuff).
If you're considering stitching together your own Python Web framework--as many shops eventually do--I highly recommend CherryPy be used as the foundation.
All the above being said, it's only fair to acknowledge that this isn't quite apples-to-apples when you look at CherryPy vs. something like Django. CherryPy isn't really a full-stack web framework, it's an HTTP server attached to a configuration and tool system that facilitates the creation of custom web frameworks.
Are there any issues in particular you're concerned about?
For example, did you modify the source to support multiple databases for read/write? Or is that not an issue and it's OK that it's coming later in the framework's roadmap?
Discussing this before starting a startup sort of feels like trying to figure out how to do salary for hundreds of employees before getting your first one.
* squid reverse proxies
* memcached
* low memory footprint httpd serving static content (e.g. nginx / lighttpd etc.)Thanks for the resource. This will come in handy.
I don't have doubts about Django scaling.
The caching framework is really cool. I did a test a couple of weeks ago, and I got a 10x performance boost, simply by sprinkling 3-4 lines of caching code to my site. That was justing the local memory caching: http://docs.djangoproject.com/en/1.0/topics/cache/#local-mem...
I'd imagine that using a caching back end like memcache would probably give another huge performance boost. It's really pretty straight-forward and usable out of the box.
I'm not disagreeing that scaling isn't only caching, but it's often a component just like anything else. Caching often helps scaling, as do multiple databases, working out bottlenecks in code...whatever else.
Caching is not scaling because by definition, it depends on a backend to provide it data.
If the backend is a database then sure, you can increase capacity by ~10x (assuming a ~90% cache hit rate), but after that, throwing more caching nodes at the problem won't do a thing if your database itself isn't scalable.
All a cache does is increase speed at decreased costs, but it is not in itself a scaling solution.
Signed, the guy who introduced Django to washingtonpost.com
(Edit: and I've since mostly switched to PHP)
Perhaps that was a longer answer than you wanted. :)
http://docs.djangoproject.com/en/dev/faq/general/#why-does-t...
But I still see it a lot, there's a lot of "not invented here" or "none of the existing frameworks do exactly what we want".
it's a bit of development overhead in the beginning, but pays of in the long run.
If I'm just coding up a small app I don't want the overhead of a framework. I might want a bit of routing, possibly some automated mvc and that's about it. Everything else in a framework I usually care little about and just slows stuff down for no benefit to me.
Coding up a "framework" that does only the very little I actually need is fast and very little development overhead considering the number of times I've done it and the fact that I've got code I can re-use.
This isn't business advice however, it's just my own personal project preference. If you're running a business you want to be able to replace developers if they quit so it's often a better idea to go with something more mainstream like a well known framework so that ramp-up time is minimized.
a) You have a reasonably-sized developer team
b) They document and test their code
c) No single developer 'owns' any part of the code
That should ensure that your developer team's "bus number" is reasonably high.
Finally:
d) You treat them at least well enough that you're not in danger of the entire team quitting at once.
That said, it can still be useful for many reasons if they base their work on F/OSS code (languages, libraries, tools, frameworks, etc.) that has a reasonably-sized community around it. But if the developers you hire are good that is very likely to happen naturally.
There are always circumstances where writing your own may make sense in the short-term, but unless it has something to do with your business' core-competencies, or otherwise leads to a sustainable business advantage, you're usually well advised not to bother.
Writing your own is often less work than trying to tailor something existing to your own needs.
Frameworks are great up to a point. If you burger flip web sites all the time, then they make your life easy.
If you only deal with one site, you will never get the flexibility of pure WSGI with some prefabricated framework.