How decoupled are the Python frameworks?

[J Kenneth King]

shocks <benmarinic at googlemail.com> writes:

> 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.
>
> Cheers,
> Ben

I've stayed away from the Java world at least professionally... but I
think I understand where you're getting.

I'm not a huge fan of web development.  Which is rather
counter-intuitive for me to say since it's been the bulk of my work
for the past four years.  It's because there's no easy way to get
around the warts.  Websites are one thing but to try and think of
these things as "applications" becomes an expensive illusion to
maintain.

The problem with thinking about these things as applications with an
interface, a controller, and a model is: statelessness!  Oh also
serialization.  Getting around these issues are pretty much the raison
d'etre for web frameworks.  Without them we end up with PHP.

As far as swappable Python web frameworks... NONE. AFAIK, they all
require some commitment to tying your application to them.  However,
there are a crop of frameworks that do minimize the pain of such a
decision: web.py and bobo are two that I've been working with (though
it sounds like cherrypy would be very good at separating dispatching
from application code).  You could of course write your stuff closer
to the "metal" so to speak... WSGI would be about as low as I go.