How decoupled are the Python frameworks?

[Diez B. Roggisch]

shocks wrote:

> Hi
> 
> I'm getting back into Python after a long break.  I've been developing
> large enterprise apps solely with Adobe Flex (ActionScript) for the
> past couple years.  During that time I've used a number of 'MVC'
> frameworks to glue the bits together - among them Cairngorm, a
> modified implementation of Cairngorm using the Presentation Model
> pattern, PureMVC, Mate (an IOC container but with an MVC
> implementation) and Parsley (IOC but you have to roll-you-own MVC).
> During that time I've been in large teams (30 Flex + 30 Java) to small
> teams (2 Flex + 1 Java).  The motivation of these frameworks is the
> decouple your concerns, allowing your apps to be more scalable, easier
> to test, and  supposedly easier to maintain.  Some do the decoupling
> better job than others, but there is also the question of "how
> decoupled is your code from the framework"?  It's all well and good
> having something clever working behind the scenes wiring and routing
> everything together, but I wonder where this leaves the code base if
> the framework, which was selected at the beginning of the project, is
> replaced with something else months or years later (i.e. the framework
> just doesn't scale as expected, the community involvement dies and
> it's no longer maintained properly, etc).  I've seen it happen and
> I've been experienced the pain of detangling massive amounts of code
> which is full of framework specific imports, methods and boilerplate
> code.  And then there's updating the unit tests!
> 
> My question is how good are the current crop of Python frameworks?
> I've used Django twice in production and didn't like that much.  The
> implementation is Django specific for starters.  I've picked up Pylons
> and I'm trying that out.  I'm not sure how well it fares?  I do feel a
> bit uneasy about the code generation that some of the Python
> frameworks do.  Pylons creates something like 20 files for a
> 'helloworld'.  It does do some great things out of the box, but I
> wonder where that leaves your own code.  After spending 3-6 months on
> your Pylons webapp, how easy is it to move to something else?  Maybe
> one of the Python IOC once they mature.  What are some good techniques
> people are using to future (framework) proof their apps?
> 
> I'm interested to hear people experiences with the various frameworks
> and how decoupled their code is from them.  The best of the current
> Flex frameworks for me is Parsley.  The only noticeable Parlsey code
> is an '[Inject]' meta tag here and there and a couple import
> statements.  All the complicated object creation and messaging is done
> higher up the chain.

I think the Pylons and maybe even TurboGears2 stack are pretty good
regarding decoupling. This stems from them bundling "best-of-breed"
solutions for e.g. ORM (SQLAlchemy), session-handling, HTML-widgets,
templating and so forth together. So in theory, and to a large extend in
practice, you can rip out individual components and replace them with ones
you prefer, and of course this overall design makes things more decoupled.

*However* there is only so much a framework can and does do when it's
supposed to stay out of your way. I for one think that e.g. the
repoze.who/what stack is an example of an over-generalization that leads to
much more hassle than it's worth it, all for the alledged advantages of
total decoupling and pluggability.

Mark Christensen wrote a blog-post about the whole coupling/de-coupling
issue:

http://compoundthinking.com/blog/index.php/2009/11/28/coupling-django-style/

Essentially, getting things *done* now is very important, and making
developers permanently jump through hoops just so they avoid coupling leads
eventually to something that is your own webframework - without the benefit
of participating on evolution of a common one that occasionally forces you
to adapt.

Diez