So, I was reading the little snake that couldn't, a pessimistic post on Python web programming by Ivan Krstic. I was rather annoyed by his Frankenweb post, but never replied to it since I figured I'd just be pissy. So maybe this will be an indirect reply to that too.

First, a point of correction: I'm not developing Pylons (as was noted in a Tim O'Reilly post), but I'm working with the Pylons developers as they are using Paste quite heavily.

Like one of the commenters on that post, I also agree that Rails is good for Python. Rails is doing a good job at describing a kind of development that Python is good for -- small numbers of good programmers making a product quickly and well. And to quote Ivan: 'If Rails has its way with the web, 2006 will be dubbed "the year of the anti-enterprise."'; that's a-ok by me too. So I think I'm on the same page as the Rails guys when it comes to basic motivation and techniques.

So, insofar as Rails is convincing people that they can do projects with small teams, with simpler goals and simpler results released in smaller iterations, that's good for Python. And yes, Rails has been a much-needed kick in the butt for Python web programming, which was not being driven forward as it should have been, and not payed enough attention in the Python community. (Incidentally, Guido was just hired by Google, so hopefully we'll see some web needs given a little more attention in the core.) Python frameworks might not have the buzz that Rails has, but they didn't before Rails, and they are doing better now than they were before, so we really shouldn't complain.

Anyway, back to the post:

Point the first: if you're writing a Python web framework that will out-rail Rails, please give up now.

No problem, no one is trying to do that. Really, not a single one. Subway was in the beginning, but they stopped really trying to do that a long time ago (incidentally it looks like Subway will merge with TurboGears).

A Rails-like Python framework with best-of-breed Python components will never be mainstream, and will never be better than Rails: it'll just be different. More Pythonic.

I, for one, like "Pythonic," and not just in terms of the particulars of whitespace or punctuation. Rails isn't Pythonic, nor is Ruby. It's not the anti-Python either, but there are real differences in philosophy, and I think Python's philosophy is ultimately better.

Also, I think Rails risks some serious risks of taking a Zope-like turn, with more risk specifically because of Ruby. Zope added one Really Bad Idea (Acquisition) that killed one of Python's best features (locally understandable code and general backtrackability). There were some other bad choices (TTW, in-ZODB code, lots of mixins and subclassing); but the worst of the choices were enabled specifically because of Acquisition. If you don't know what Acquisition is, think of it as crazy attribute dynamic scoping.

Ruby doesn't have Acquisition, but it also plays loose with classes and interfaces in a way that makes code hard to understand locally. Of course nothing is inevitable, but there's risk. And the first generation of programmers is usually enthusiastic; any failure is a personal failure, so you can gloss over those things. It's the second generation that's going to be less enthused, that's going to stare in bafflement at these classes that mysteriously spawn methods, and trying to figure out what's going when there's an exception in dynamically generated code. You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong.

That's a risk for Rails, but we can't just hang around and hope to catch people who drop from Rails. But Rails is hardly answering everyone's needs. And no, Seaside isn't answering every need that Rails isn't answering.

Python has an opportunity to do something Rails isn't trying to do, that DHH specifically doesn't want to do: create a heterogeneous web programming environment. The "Frankenweb" is a feature, and it describes the web we have, the software we have, and the future that is inevitable. The world was never all J2EE, or ASP(.NET), or PHP, and it won't be all Rails either. The Python web framework diversity is just a microcosm of that; it's not necessarily good, but neither is it necessarily bad.

There's a certain hubris to the idea that a framework should not reuse external code (something that both DHH and Adrian Holovaty basically asserted at Snakes and Rubies). Yes, you can get by without using other people's code, and often you can make it work fairly quickly and on a timescale you control, and the specific gains you get from reusing code may not match your initial expectation. But there's also a presumption that no one else is ever going to make code worth using, that you will always be the cutting edge, that you can assimilate every idea without assimilating any code. But you just can't be the cutting edge of everything; and once you aren't, people have to choose to stay or to go.

Well, people don't have to stay or go, but they will if you don't have a plan. Frameworks can fit together, but it's hard. It's hard, but it's good exercise. The project that is reusing code right now will be able to reuse code in the future.

That's one thing Python can do. Another is actually try to pick up where PHP leaves off. Rails doesn't do any of the stuff that PHP does well, it merely provides a landing spot for disaffected PHP programmers. The beauty of PHP is that they are constantly sloughing off disaffected programmers, and yet their numbers still grow. (If PHP is wrong, do we want to be right?) PHP grows because there's lots of useful applications -- some quite good, but you don't even have to be good to be useful. You install an app, you customize the app, you realize later you are a PHP programmer. There's other good features too, but anyway, we can provide useful applications that don't require an understanding of the framework to install and start customizing. The last system like that (before PHP) was Perl CGI; and they did pretty damn well for themselves during that period. Python can be the next system like that, and hell, I even have a plan. (Zope 2's growth was very similar, applications first, but Zope 3 is not at all like this. But it could be! My plan includes everyone who wants to participate! I love you all equally!)

And that's only like two ideas. Rails has a message, and it has an implementation that fulfills that message. That's not bad, it's certainly working out for them. But if you think that's it, that there's nothing left to work on, then you sorely lack imagination.