Ian Bicking: the old part of his blog

Re: Handling a Diversity of Frameworks

Whenever I hear the word "framework" my alarm bells ring. And I think that's the case with many people in IT.

But sometimes it does make sense to us a framework.

Choosing a (web) framework means taking risks. (Risk of "wrong" web framework selection, risk of steep learning curve, etc.) The smaller the choice the easier is the selection.

To be on the safe side, many people want to go mainstream. But there is no Python web framework mainstream. Sigh.

In order to be successful and survive, frameworks need a critical mass of users and developers. I think the diversity of Python web frameworks prevents one of those to get the critical mass. (I would say that Rails reached such a critical mass.)

As long as none of the Python web frameworks reaches such critical mass, they can't profit from self-energising (positive feedback) effects.

Comment on Handling a Diversity of Frameworks
by Bishi

Comments:

I know people are wary of frameworks, and I am too. But to clarify the discussion, "framework" can mean two things:

  1. A set of conventions.
  2. A library that tries to generalize logic.

The first is the natural result of dealing with a specific domain. This is why all web applications use a framework, even if it's a custom framework for the application. This set of conventions needs to be sufficient, as well -- the standard cgi module isn't sufficient, so if you use it you'll still end up creating a framework if your application is very large or general at all. And even that module is a mini-framework -- just not a very good mini-framework.

There's a real overhead to conventions, so if a framework is just (1) then it's still a problem. There's new words, new constructs, new interfaces, and those tend to infuse the code that uses a framework. If they don't, if those concepts are internal to the library, then it's not very framework-like. But it can't be helped sometime, you can only hope you use terminology that is clear, minimal (but sufficient), and maps well to the domain, and is conventional. Custom frameworks are most minimal, but least conventional, and tend to embody many nonconventional ideas of the application author.

The second -- generalizing logic -- is much more dangerous, though often just as necessary. For instance, if you didn't generalize logic a web application might start with:

if PATH_INFO.startswith('/contact'):
    import contact_form
    contact_form.run()
elif PATH_INFO.startswith('/article') and PATH_INFO.endswith('/view'):
    import article_view
    article_view.run()

And so on. Because a simple thing like URL parsing is very logic-heavy. And if you use something like SimpleHTTPServer, you'll end up writing exactly that code. Or you'll end up writing code that imports modules and does path matching generally, moving that "code" into "data" (a URL mapping or an algorithm for resolving URLs). Then you've created your own logic-generalizing framework.

In this case you hope the framework is minimal and transparent, and follows several important rules (which I have in my head and somewhere on disk, but I haven't written down on this blog).

Paste has a little of both kinds of framework, and leaves a bunch up to frameworks that run on top of it. This causes problems, but I can only say that I think hard about the issues and I'm designing Paste with these issues in mind. Decoupling makes a framework more minimal, because it is locally-understandable, and Paste is all about decoupling. A common infrastructure encourages convention. And a wide base demands that the domain be well covered.

# Ian Bicking