I have tried to be happy with django, I really have. | Hacker News Reader

I have tried to be happy with django, I really have.

reddit.com

35 pointsbensummers44 comments

The OP makes a few points, most of which I disagree with (they're mostly a matter of opinion).

One valid point he makes is: "Confusion on where to put code, and too much flexibility". Can't say how it is in other frameworks, having never used them, but The Django Book had far too many cases of saying "you can do it here or there, it's a personal preference". I don't want to make a choice when I'm new to a framework, I want to be told what's correct and what isn't!

I think it's a matter of what kind of framework you want to be. Rails is very opinionated: Fat model, skinny controller, and use helpers or you're a fool. Django is less so: Put it here, or there... whatever you like. It really comes down to the philosophy of the underlying language I think. Ruby in general is kind of opinionated, and python less so.

One of Python's doctrines is "There is only one correct way to do things", which suits my philosophy perfectly: I don't like having to make decisions, I like it being obvious what the correct way of doing things is.

That's why Django's "flexible" approach seems odd to me.

Another one of Python's doctrines is that practicality beats purity. Given the differences between a lot of websites, I can see a one-size-fits-all model going out of the window pretty quickly. Especially so given all of the wa-wa-I don't like the auth/admin/predefined data fields that seems to be going on here...

I would have said exactly the opposite - Python is opinionated ("only one way to do it"), whilst Ruby is far more perlesque in it's "anything goes" philosophy.

Yep Ruby is definitely more TMTOWTDI (http://en.wikipedia.org/wiki/Theres_more_than_one_way_to_do_...) whereas Python is antithetical to this.

Python is quite opinionated. http://www.python.org/dev/peps/pep-0020/

It's impossible to say, because at no point in his rant does he give any concrete detail on what exactly he was trying to do. I've never had any issues knowing where to put code in Django, or in reading its source code.

It is confusing only at first glance.

Django unambiguously states where to put your models, view functions, forms and the url patterns. Those are grouped into an 'application', which you can have many and define logically by the general task you want them to solve.

Inside the model, view, form and url files (settings too for that matter) you write your code according to the style and philosophy of Python.

For that reason Django can not and must not define for you in what other file should you keep and what name should you assign to some class you write that is required for one of your views or another.

If you don't feel comfortable with the structure of your Django code, it's best to look into general good practices of Python programming, because Django is Python!

IIRC, the way it works is that Django specifies where in the package namespace it expects things. But you can always load anything into that package namespace. If you have a file specifying models, you can either:

     class SomeModel(...): ...
     class SomeOtherModel(...): ...

     from some.other.place import SomeModel
     from yet.another.place import SomeOtherModel

and it's the same. Django is Python.

In fact this is another instance of what I complained about yesterday: http://news.ycombinator.com/item?id=1605928 People see the "DSL" and all knowledge of the underlying language goes flying out the window. Models are actually very, very non-magical, and anything that you do that ends up with class in the certain namespace simply is a model, and any Python language feature that lets you produces such a class can be used to make one.

This would be the same thing as Rails... yeah, it'll load everything in app/models by itself, but anything else is just a require away.

I'm the opposite, e.g. I find Django templates too restrictive.

I have used Rails, but my web framework of choice is Tornado; I really like their design choices.

The real issue I have with Django - and extensions such as comments - is that in some ways it feels like a CMS masquerading as a framework.

Take for example contrib.auth - it defines User, Group and Permission models for you. Frequently this is an issue - what if I don't want a username of 30 characters ? What if I want OpenID authentication instead ?

Sure, you can override this but then you find that a whole lot of 3rd party apps - comments, admin etc - rely on these models, which in turn depend on lower-level functionality such as the ORM or templates. The very fact that you have a framework telling you what your data model should look like just feels "wrong".

Does this mean that you shouldn't use Django ? Absolutely not, there are many projects suited to Django - especially content sites where you are putting together large building blocks with some homemade glue. But I've found it more trouble than worth for smaller projects, or where you have very specific requirements - in these cases (assuming you want to stay in Python) - I'd recommend Flask or Pylons.

Unfortunately Django has become the new Blub framework for Python web development, which means it's used by companies by default, rather than being a useful but limited tool in the toolbox.

Alternate login backends are supported and documented. OpenID is as easy as a package install and adding a few settings. https://launchpad.net/django-openid-auth works well and it integrates into auth.

You completely missed my points:

1. The framework should not define your data model.

2. Many 3rd party apps depend on the existing User and other auth models.

I still must be missing your point... What would you prefer? If there was no contrib.auth then at best you'd have to do it all yourself which still means customizing third-party apps.

Authentication is something in my experience that is specific to an individual project. I don't want to be told what database schema I must use to store my user data - that's a specific project requirement (unless I'm building a cookie-cutter site, which Django is good at, as I've stated).

So what do I want ? For authentication there are some common requirements:

- session/cookie management to store a user ID (or other info)

- hooks/middleware/whatever to allow me to check user credentials on each request

- safe hashing/encryption of passwords

- form processing/validation

- integration with OpenID, oAuth, LDAP etc

If a framework, or libraries, provide these then that saves a lot of time and effort, and allows me to create a tailor-made solution.

You can do all of these with Django, but not unexpectedly it won't magically work with other people's code. I don't know how it could, if there's another framework that does this I'm interested.

contrib.auth can be made to do most of these if you still want the ability to play nice with other people's code who expect you to use auth. You'll have to create and manage User objects which it sounds like you're unwilling to do, but you can't have it both ways.

I think having it there is better than not. In most circumstances it saves me a lot of time. If I come across a circumstance that I can't use it then I'm just back to where I would be anyways and will have to write a lot more code and modify 3rd party apps.

Exactly, it saves a lot of time when you want a cookie-cutter site using lots of 3rd party apps. Not knocking that - there are lots of cases where that's exactly what you need. But this is what reminds me more of a CMS like Drupal than a framework - blocks of content managed by a single admin and authentication system.

When I want to do something more original and specific where I don't need all those apps, Django just gets in the way - and that's when I turn to a more lightweight and flexible framework.

Use the best tool for the job. Sometimes Django is that tool. The problem I have is with companies and individuals who think it's the only tool.

You forgot the pony.

Interesting. As a Rails guy, I'm a bit envious of a nice default authentication component being built in as long as it's possible to override.

I've used both pretty extensively. The authentication system in Django isn't something to be that jealous of. It's not that it's bad or anything, it's that sites have very different authentication needs and it isn't a lot of code. Examples: some sites need email verification, some don't; some sites want authentication by email address, others username; some sites want usernames, some don't (ala Facebook). And, it's important to note, Django really only takes care of the model part (it doesn't provide the templates and controllers/views). Creating a User model in Rails isn't that hard.

The main reason (in my opinion) that Django has an authentication component is because it has an admin section. That requires authentication. The admin section is something to be jealous of because it's a lot harder to duplicate. Creating a user model isn't that hard. While there have been Rails projects trying to implement an admin system as nice as Django's, they aren't as nice and clean as I'd like. And that's a lot more complex than a simple User model.

And yes, I'm aware that one can do lots of things to extend the Django User model. Examples: while the User model doesn't require an email, you could have the form you build require an email; in Django 1.2, you can have "@" and other email characters in usernames and then just reference the username attribute rather than the email attribute when you want the email; in your controller/view, you could first search for the user by email and, if found, grab the username from that object to pass to the authenticate method. It's more that a User model isn't such an incredibly complex piece of code and I find that different sites often want slightly different things that make it just easier to make one's own.

TL;DR: Be jealous of the admin section, not the authentication system.

Perhaps I misunderstand your assertion, but I do want to clarify that django does provide views for user management in django.contrib.auth.views. It includes login, logout, and password reset/change views. Granted, it doesn't include templates, but those are pretty straightforward and site-specific anyway.

> what if I don't want a username of 30 characters? What if I want OpenID authentication instead?

  contrib.auth

Django is as minimal as you want it to be. People seem to have a hard time not using everything.

OK, you take out contrib.auth (and other contrib.* packages, including the admin).

What's left that's actually compelling about Django vs other frameworks ?

Here's the problem: "I have spent 2 years trying to learn django, why should I waste it? I'm 19 years old now..."

A) 2 years of programming experience in any language is not a waste of time even if you never touch that language again, B) Sunk costs, if the previous 2 years were a mistake, then don't repeat that mistake by sticking to a language and framework you don't like. C) 2 years is nothing.

D) You're fricken' 19. You're supposed to be "wasting time". You can't find the right path for you until you determine some of them are dead ends.

Absolutely. He needs to be spending time reading literature and visiting art museums and hiking in the woods and fooling around with girls. There's plenty of time to work when you're old.

As I sit at my desk at age 20 with a cup of coffee. :(

At 20 I was running around playing GI Joe in the forest. It wasn't until 23 that I realized that shit was real.

At 35 now I certainly don't consider any of that time wasted. I would suggest if you are "frowning" now - as you put in your comment - to get out and do something that doesn't make you frown... the cup of coffee will still be there, I guarantee it.

-1 On the community - StackOverflow alone is enough to find / get you answers to 99% of your questions in seconds.

+1 On the extensions - They almost never work out of the box and require extensive changes (or usually rewrites). Seems like Django people never figured out how to create portable apps for Django. (And the comment app is Horrible !)

I feel the main problem with extensions is that the "application" level of abstraction doesn't work very well in practice. It was an ambitious idea, but there are too many dependencies for that to be feasible.

That said, I still like Django for quickly banging out moderately complex apps.

It's okay to not like frameworks. My opinion is that frameworks, in general, make easy things a little bit easier, and make hard things even harder.

Completely offtopic, but I replied to the OP (on reddit) and remembered a problem of my own that I'm having, and I can't quite figure out how to solve.

Nginx + Django -- I have wildcard DNS on mydomain.com, and want to support customers such that customer1.mydomain.com gets its own database. I thought I'd be able to use fastcgi_param to inject a variable to fcgi, and then read it with os.environ.get('fastcgi_param'), and then 'IF' the settings.py to import customer1.settings.py (to override the database), but I can't seem to make it work.

Any thoughts?

http://news.ycombinator.com/item?id=1566709

Well, thanks for the response, despite the downvote. That said, it may seem like a 'bad' idea, as I understand the pitfalls in managing a consistent data schema across n databases, but it also seems like a much more performant idea than building a customer table and having to do an extra join on every read query for every ticket for every logged in user.

I didn't downvote you, bmelton.

    it also seems like a much more performant idea

Why is performance important to you? Presumably to make it cheaper to run, in which case I suggest you weigh the costs of coding and maintaining multiple dbs against the cost of that extra join. Note that the multiple db approach is already costing you since you are still trying to get it to work while you could already gave the single db approach in place relatively painlessly.

There are several options here. First, you could use the Django "sites" framework, which has the advantage of being idiomatic and familiar to other Django developers:

http://docs.djangoproject.com/en/dev/ref/contrib/sites/

Second, you could define a database backend per customer (using the Django 1.2 multi-DB support) and write a custom database router that is aware of your custom FastCGI environment variables:

http://docs.djangoproject.com/en/dev/topics/db/multi-db/

Third (and best, IMHO) would be to run separate FastCGI processes for each customer, and route appropriately from Nginx. This approach is obviously the most complex setup, but it has the major advantage of letting you run every customer's FCGI backend under a different user id, offering yet another level of protection against data leakage and other security issues.

I like the third option quite a bit (though what I was trying to do looked more like the second) but the problem that I'm having moreso than anything is in trying to GET a fastcgi parameter as a variable in my settings.py.

I'll carry this over to SO, as the downvotes suggest that this is not only offtopic, but inappropriately placed altogether, but thanks a million for your insight.

The other advantage of the third option is that you don't have to write a whole bunch of auth/filtering code to only show customers their own data. Row-level permissions are relatively straightforward in Django, but it's still easier not to have to deal with them.

Is it really that bad? I get the impression that most are happy with Django (or maybe that is other python frameworks.....).

It's not really that bad. I'm baffled how he could spend 2 years with Django and not understand how to do the things he's complaining about (not to mention python).

I think it was just a bitching session.

Model package management: It's a dirty kludge. Not documented (last time I've checked), I had to search hard to get it right.

You must edit models/__init__.py such that:

    import X from Y

...and then each model must have

    class Meta:
        app_label = 'foobar'

Without the meta information Django cannot load the models inside the package, it imports only models.py.

May be it should be automated (model loader)? For instance, the model loader could parse the directory tree and import all necessary info it needs(meta information, optional), all is needed is a function for it :-/

edit: Format, gramer :)

edit2: Phah! OK. I'm gonna do it. Automatic model loader function, Django extension :) (May be next week...)

Ok HN :-/

However, for those interested in model package loading automation, I started a section on reddit: http://www.reddit.com/r/django/comments/d1ulg/automatic_mode..., may be I'm wrong...

Sorry for bothering you...

Reply on news.ycombinator.com