You write in the penultimate paragraph "Python can be the next system like that, ..." For me, this sounds like a deja vu. I heard it when the shining star of Perl CGI started to fate. I heard it again when Zope raised to relieve us all. And now again...
... and now again we should try to make it work...? That's what I read from the history, not "it didn't work before, we shouldn't try again." Zope has some good goals, ones which we shouldn't abandon even if the product wasn't manageable, and we should learn lessons from the problems Zope had.
I guess I should probably try to analyze exactly what it is that PHP is good at (and Perl CGI before it); but you can probably imagine what lots of its good features are as a platform.
Do I care about wether SQLObject, Og, ActiveRecord, Hibernate or whatever is used? Not at all to be honest.
Maybe not, but I sure as hell do. And if you start using Django heavily, you will start to care when another framework comes along and uses a different ORM. And you will care what that ORM does, and you will care about URL dispatching, and all that stuff. And if you want to use that new framework, you'll care about how hard it is to maintain both alongside each other.
If you are just jumping ship and moving to an entirely new stack, these things don't matter to you. And maybe targetting those people is a perfectly good strategy -- for some stacks it's probably just as well that they are abandoned. So Rails has seen lots of PHP and Java programmers; and because previous investments in Ruby have been rather small previously, it's been able to get the Ruby programmers as well.
If you want to get people into Python the same way, that's fine. You won't get me, because that's not where I am. More than once people have asked me: why not just all use Django? Personally I don't know what the hell they think I'm going to say.
But even then, that's fine. If you had to buy into reuse to participate in the kind of WSGI-based stack I imagine, that would invalidate the inclusiveness of the stack itself.
In my eyes a lot of Javaism is showing up in the community, which is in the end not compatible with the idea Rails follows and a lot of people enjoy to follow in the future. Pragmatism is something, that (we|the) Python guys sometimes lack.
There's some vague accusation underneath these comments that I dislike (ditto the Frankenweb post I reference in the article). It's using Javaishness as the same kind of blunt stick as not-Pythonic-enough.
These are practical issues. Being able to install an application easily is practical. Being able to embed other applications is practical. Introspection and uniformity at some level is practical. And yes, reuse it practical, at least if you think that anything you build matters.
Maybe you can't imagine building anything that can't be built in a few weeks today. I can imagine those things, things that I want to build in a few weeks but can't. If all we do is write and rewrite and refactor the same kinds of stacks, we can't get there. At some point we have to put pieces of the stack behind us, to make them stable (as in API-doesn't-change, as in mature and boring), to create a real foundation. That simply can't happen on the level of a typical web framework -- you still have to have a framework, at some level you have to get things done, but the framework isn't where we can build up that foundation.
I'm sorry if you don't understand the motivation or purpose of some of the things I work on or talk about. I do want to explain them better, but sometimes I don't. But labelling that confusion as though I'm therefore caught up in meaningless academic discussion is a little offensive. If you think it's too complex, say so; if you think it is unapproachable, say so; but there are deeper and more abstract ideas underneith the surface of immediate pragmatic concerns, and they do matter sometimes.
I would like to add that all the buzz around the frameworks is often generated by people doing only web applications and not having to access other business models/logic from within. These needs to integrate, reuse the ORM coming from the business side of the application, are often simply not addressed today. So +1 for the FrankenWeb, because my web is linked to grids and software stacks that cannot be handled by a "unique" framework.