Hacker News Reader

Comment by cageface | Hacker News Reader

The overwhelming dominance of Zope back in the day really held back the Python web development world and I worry the same thing is happening again with Django. Django could really benefit from a Merb breathing down its neck.

The Rails core team and the dev process is totally open and the DVCS-centric model makes it really easy for anybody to jump in and contribute. I can't see why this wouldn't work for Django too.

View on HN

I think there is plenty of other opinionated* people/groups in the Python web developer community to keep the Django community on their toes. For example, Flask which was mentioned in the slides we are currently discussing. Flask is from the same person/group that did Jinja, Werkzeug, and a couple other cool things. Pylons has a good user base and plenty of steam. There is also mavericks like Ian Bicking who wrote Webob and Paste (which Pylons is build on) who prefer the sans-framework approach because it is simple in Python to glue together the various libraries needed for a "framework".

Plus the addition of AppEngine with doesn't play nicely with Django due to BigTable means people look at other solutions.

Also, the Django community, especially some of the core developers do seem to respect the opinions of these other people and groups. I have seen in mailing lists and IRC where core devs agree that Django to a wrong turn here or there, but correcting that turn is a slow process. Overall, I think the philosophy of "Do it right, not right now" is a great one, and it needs to be considered with correcting mistakes.

Opinionated may not be the best term, but it is close. I really mean people that are vocal, that are respected in the community, and groups or projects that great support and communities.

*There are ways to use Django with AppEngine but all have issues. Also, AppEngine now has some sort of SQL support, but I haven't looked into it.

I've avoided Django on AppEngine due to the vagaries of the AE datastore, and the extra time and planning it takes to get things working efficiently; I'm wary about using any framework not specifically designed for AE. Fortunately the webapp 'framework' that comes with AE is quite usable, though not exactly feature-packed.

Perhaps I'll look at Django on AE again in the future, once I have a better understanding of how to build things correctly.

EDIT: I don't think the advent of App Engine should have a major effect on Django development; my general thought when developing AE projects is to wish I was using a real server, one under my full control.

I have tried Django on AppEngine using AppEngine Patch, but at this point, I don't think it is worth it till Django has non-relational database support. If I were to build something on AE right now, I will try Flask or Kay.

Have you tried Django Appengine?[1] It works pretty well and supports most things in django (including the admin interface).

[1] http://www.allbuttonspressed.com/projects/djangoappengine

I haven't, but I am not currently doing anything major on GAE right now.

I had wondered whether that works, I'll have a look at it for the next job. Anything with a working admin system will make my day.

Zope seemed to have great people behind it, and was very solidly built, but it seemed a lot more monolithic, which ended up polarizing people.

Django really benefits from the ability to swap out everything. People who hate the default libraries just find something better to use.

No migration? Use South. Some people run Django on Twisted or Tornado. There are different template libraries that people use. I'm not sure if the model layer can be swapped out so easily (without messing around with custom user authorization), but there's nothing to stop people using django models for authorization, and a separate database interface (even a no-sql one) for other data.

Do you really have used Zope and Django if you say that the former is monolithic and the latter allows easy swap out its components?

If you're going to swap out everything, are you really using Django to begin with? Why not just use TurboGears[1], which seems based on the idea of swapping out standard components?

[1] http://www.turbogears.org/

Yeah, you lose the full-stack benefits of Django pretty quickly once you start swapping out components. If I wanted a more customizable Python stack I'd pick one that was designed to work that way from the beginning.

I've built a couple of small Flask apps and I like it too. Django doesn't really seem to have a direct competitor in the same sense that Merb was for Rails though. Merb and Rails provided a similar developer experience but had some significantly different architectures. Things like Pylons and Turbogears are much more roll-your-own than Django and microframeworks like Flask are great for what they cover but usually app requirements will dictate Django vs Web.py, for example, and not developer preference.

Django has plenty of not-so-alternative projects breathing down its neck and they're well aware they have to keep up. Personally I think it helps the rest of us to some degree for Django to be out at the front accommodating all the crushing masses of new users while smaller projects, not as quickly discovered (but discovered enough) enjoy moderate but well-tempered userbases.

I agree that the Rails model seems to be working well for them (especially since seeing Rails 3), but it always comes down to the accepted decorum of the community. Its really up to them.

Anyone can contribute to Django right now; just like anyone can contribute to Rails.

Only a group of core maintainers can merge those contributions into a core, shipping release. So how does the DVCS make that core think, work or release any differently?

I think the DVCS issue is not part of "what is wrong with Django."

Like you said, anyone can contribute, and core developers will be responsible for reviewing and integrating those contributions, regardless of the VCS. There are even unofficial mirrors on Github and Bitbucket if someone wants to go that route.

All that said, if Git or Hg (or other DVCS) would make some of the developers tasks easier, like reviewing patches (in the form of pull requests on Github), managing branches, tagging releases, etc, I think it is a worthwhile switch.

Edit: Changed core developers to developers in the last paragraph/run-on sentence because it might benefit all contributors.

Except that if the Django core developers thought that using Git, mercurial, or github would grossly improve their workflow, don't you think they'd use it?

They may be perfectly comfortable with their current tools - we agree though, this is not a source control issue. It's is a personnel, and social issue. DVCSes are not magical, and github isn't a cure-all.

If the problem is with the people; we have to fix the people, get new ones - not change the tools.

Reply on news.ycombinator.com