You work for me, Computer

I agree I'd rather go schema first than model firs...

2009-10-29T13:30:12.317-07:00

I agree I'd rather go schema first than model first. As a side note though it's interesting to think about it in the context of the whole NOSQL mouvement that's been gaining a lot of traction over the last year. Facebook, LinkedIn or Amazon for some subset of its data and others are doing away with the relational stores and going with pure key/value pairs persistence.

Not relevant for every application but very interesting nonetheless.

Piping objects has draw backs too. Here's a case t...

2009-10-23T13:38:17.654-07:00

Piping objects has draw backs too. Here's a case that came up on the internal PowerShell mailing list...

Unix:

cat foo | wc -l

PowerShell:

Get-Content foo | Measure-Object -line

Ignore the line length, as I didn't use any aliases for the PowerShell version. The issue here is that Get-Content returns a String, not a StreamReader. The result is that for large files, the entire String must be read into memory and for really large files, swapped back out to disk!

You could easily work around this with objects; this example is just to show that objects have drawbacks just as byte streams do. Everything is always a balance. I like the Unix approach because it is a simple system with drawbacks that are well understood. I dislike the object approach because it is a complex system with less obvious drawbacks that don't bite you until much later.

Unix is optimized around flat files windows is opt...

2009-10-22T21:04:21.830-07:00

Unix is optimized around flat files windows is optimized around objects. It's not the they don't understand Unix. The Powershell Team has a strong unix Background. It's just just that M$ has 87% market share and a trillion dollars in the bank share that says F@ck unix.

Sorry but no: Pipelining objects is much smarter. ...

2009-10-21T06:21:30.503-07:00

Sorry but no: Pipelining objects is much smarter. You can still pipe strings or binary data if you want, but you don't have all the drawbacks.

And then there's the security implications. While theoratically possible, are all your scripts safe against whitespace|"'` injection? Piping objects is sooo much easier AND it does not kill your system if the bytestream contains `rm -rf /`.

Just my two cents...

@Martin: The "original target use" argument is no ...

2009-10-07T14:17:32.627-07:00

@Martin: The "original target use" argument is no longer relevant. Django is being pushed as a general purpose web framework for developing sites or apps, big and small.

@Ezequiel: I'm not building something Twitter big. I'm building something that has to deal with real user data and survive real design evolution. The problems I describe affect any application with any longevity of any kind.

I agree with Martin, Jacob Kaplan-Moss himself sai...

2009-10-07T12:37:59.367-07:00

I agree with Martin, Jacob Kaplan-Moss himself said that, when you get to a point where you're building something really big (e.g. Twitter) you basically have to throw your framework away.

Django is really good, but, like any technolgy, sometimes is not enough.

These are all good points, and largely irrelevant ...

2009-10-07T11:28:17.125-07:00

These are all good points, and largely irrelevant for someone developing to Django. Yes, if you are using Django to develop to a long-term data store, enterprise data, etc., you are dead right, and you should be using SQLAlchemy with Django instead of the Django ORM.

However, consider Django's original target use: a newspaper, on the cutting edge, putting up quick apps on-the-fly with a very short development cycle. A CMS. A Polling app. A Blog. Think about the type of apps that people actually build with Django, and you will find that the Django ORM makes perfect sense. Short development cycle. Easy deployment. "Good enough" query optimizations.

Without the changes in Django 1.1, modules were th...

2009-09-10T17:41:17.777-07:00

Without the changes in Django 1.1, modules were the only recursive mechanism; too heavyweight for my taste. The 1.1 beta was released in March. I had developed my own solution to this problem several months before then.

Even with the 1.1 improvements, Django doesn't meet my other requirements: namely binding URL segments to the database and creating breadcrumbs while filling a template context dictionary. Since that work involves parsing request.path myself, I might as well just bind (.*)+ and do my own routing. It was relatively trivial.

You can have non-flat URL routing. After your firs...

2009-09-10T17:30:21.483-07:00

You can have non-flat URL routing. After your first point demonstrated a failure to grasp more than the basics before whining, I tuned out.

Nested URL routing confs and includes (new in 1.1) are what you should have used instead of bitching on the internet. It wouldn't have made you seem as cool, but you would have gotten the job done instead.

There is nothing that Django's routing can't do. I...

2009-09-09T14:54:20.994-07:00

There is nothing that Django's routing can't do. In fact, the first version of this simply generated Django routes. This is about making is faster and easier to define hierarchical permissions and trees of URLs in a way that queries the database on a per-url-segment basis.

in terms of* I meant. Spelling is not one of my st...

2009-09-09T13:44:31.693-07:00

in terms of* I meant. Spelling is not one of my strongest areas eh?

I am sorry I still don't get how this serves as an...

2009-09-09T13:43:26.119-07:00

I am sorry I still don't get how this serves as an improvement over Django's url system?

Can you provide me with a concrete example of what you cannot do in Django in terms or url-routing?

I'd recommend taking a look at Werkzeug for your r...

2009-08-28T11:02:00.780-07:00

I'd recommend taking a look at Werkzeug for your routing & other wsgi basic needs.

As a follow-up to the previous post, Jinja 2 makes for an excellent templating engine (think django but much faster and without the stupid limitations).

And as a shameless plug, have a look at WTForms for your forms: http://wtforms.simplecodes.com/

Child views are not "hard coded". They are determi...

2009-08-26T11:37:56.782-07:00

Child views are not "hard coded". They are determined by the children method. You could pass segment, but it would be easier for the bind method to just store something on self for use later.

I looked at Restish a bit. It seems like a nice library; definitely the closest to my taste from what I've seen.

You are hardcoding child views in the children met...

2009-08-26T02:10:31.749-07:00

You are hardcoding child views in the children method of each view which means the view can't decide what (type of) children it has based on the current path segment. For example, I have a use case in which some content types can contain children of more than 1 type, so for example /foobar/child/ can either be a TypeAView or TypeBView depending on whether a TypeA with name "child" can be found or not - if it cannot be found, TypeBView will be returned. If your children() method took a path segment as an argument, it would probably solve this problem.

BTW have you checked out how Restish resolves/dispatches URLs? I think they have it right when it comes to dynamic URL trees.

For anyone interested and tracking this thread, I'...

2009-08-24T23:06:08.220-07:00

For anyone interested and tracking this thread, I've posted a follow-up:

http://blog.brandonbloom.name/2009/08/url-routing-and-views.html

pylons is great being a framework that allows mixi...

2009-08-24T22:43:23.229-07:00

pylons is great being a framework that allows mixing and matching libraries.

My ideal would be

Werkzeug
Jinja2
SqlAlchemy
Babel
wtforms (FormEncode and htmlfill's pattern of inserting html is gross)

I would probably build on Django's idea of applications and middleware as that's a good paradigm.

This is a subset of the reason for why we made web...

2009-08-21T00:45:57.084-07:00

This is a subset of the reason for why we made web2py. Thanks for explaining them so clearly.

I agree, PowerShell is way better than the primiti...

2009-08-20T18:53:37.639-07:00

I agree, PowerShell is way better than the primitive, DOS style Windows CMD. However, it's nothing like a normal Unix shell for me... and I'd rather just use cygwin.

http://jng.imagine27.com/articles/2007-07-12-16382...

2009-08-20T12:25:00.174-07:00

http://jng.imagine27.com/articles/2007-07-12-163820_red-vs-blue.html

A somewhat dated (and biased) comparison of Python/Django with Ruby/Rails.

"Beyond Django's specific weaknesses, I've come to...

2009-08-20T11:43:08.594-07:00

"Beyond Django's specific weaknesses, I've come to believe that the schema-generative ORMs paradigm is fundamentally flawed."

I too would like to see some more detail on this. I maintain a Ruby ORM called DataMapper, and while the API is completely different, it is still declarative. I prefer the declarative style to ActiveRecord, since I can specify rich types and constraints than I could reflect from a database. The way I see it, at some point the schema needs to be defined, and I'd rather do it in a richer DSL and have the schema, validation and other constraints generated from that.

Even so, I'd love to hear a different view point.

@Dead Man: I’ll probably publish something about o...

2009-08-20T11:15:29.566-07:00

@Dead Man: I’ll probably publish something about our approach to URL routing soon. It seems that several people have shown interest in it.

@ars: Yes, I will probably be writing about declarative ORM layers in the next week or so.

@Andrew Shultz: We’re not doing a whole lot of automated testing yet. Small helper functions typically have doctests, we’ve got a couple unit tests, and we’re currently playing with Selenium for full tests. I’m much more confident in tests which drive the UI than tests which only poke at the views.

@proteusguy: I just read that blog entry and will respond to it separately. Again, I’m not bashing Django so much as I am saying we’ve been slowly choosing tools that better fit each need as we identify those needs. Technical feasibility aside, we’ve been looking for a path of least resistance to accomplishing our goals and this post was just to describe them.

@Alexei: That’s the impression I got too; Django would have had greater longevity on my tool shelf if I needed a highly customizable CMS. I don’t need more flexibility, I need less constraints.

@RJ Ryan: Like I said about, I’ll try to follow up with more info about our URL routing system. What needs we had and why I felt I had to subvert Django to get them.

@Shantanu Kumar: There are already too many choices of Python frameworks! :-)

@Sebastien: Thanks for the PAML link! I’ll take a look at it. As for CleverCSS, I don’t see a need to switch from SASS. We only need Ruby and SASS installed on dev machines, the server only ever works with the compiled CSS.

I use pylons + mako + sqlalchemy and love it

2009-08-20T10:18:04.171-07:00

I use pylons + mako + sqlalchemy and love it

I totally agree with RJ Ryan. No framework will s...

2009-08-20T09:17:59.466-07:00

I totally agree with RJ Ryan. No framework will suit every project, but Django covers a lot of the basics in a way that's good enough and doesn't get in the way when I need to extend it. Still, thanks for telling us why it wasn't the tool for you.

If you're looking for a HAML Python equivalent, th...

2009-08-20T08:58:09.822-07:00

If you're looking for a HAML Python equivalent, there is PAML (Pamela) at http://github.com/sebastien/pamela -- also, you can check CleverCSS as a SASS replacement.