Hacker Newsnew | comments | show | ask | jobs | submit login

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!




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(...): ...
or

     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.

-----


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.

-----


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.

-----


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/

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: