How decoupled are the Python frameworks?

[shocks]

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

 

[J Kenneth King]

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.

 

[Martin Sand Christensen]

[...] (though it sounds like cherrypy would be very good at separating
dispatching from application code).

True. In CherryPy, each page is represented by one method (the 'default'
method is an exception, but that's not for this discussion). This method
is expected to return a string representing the page/resource that the
user requested. At this simple level, CherryPy can be considered more or
less just a HTTP server and dispatcher.

However, we all know that this isn't where it ends. When we want to
handle cookies, we need framework-specific code. When we want to return
something other than HTML, we need framework-specific code. The list
goes on.

However, with a reasonable coding style, it can be quite practical to
separate strict application code from the framework-specific code. Here
the one-method,-one-page principle is a great help. For instance, we
quite often use decorators for such things as authentication and role
checking, which is both very practical and technically elegant. For
instance, if a user must have a CAS single sign-on identity AND, say,
the administrator role, we'd do as follows:

@cas
@role('administrator')
def protectedpage(self, ...):
# stuff

If the user isn't currently signed in to our CAS, he'll be redirected to
the sign-in page and, after signing in, is returned to the page he
originally requested. The role decorator checks his privileges (based on
his CAS credentials) and either allows or denies him access. This adds
up to a LOT of framework-specific code that's been very easily factored
out. The CAS and role modules behind the decorators are, in turn,
generic frameworks that we've merely specialised for CherryPy. At some
point we'll get around to releasing some code.

As a slight aside, allow me to recommend Meld3 as a good templating
library. It's basically ElementTree with a lot of practical templating
stuff on top, so it's not a mini-language unto itself, and you don't
embed your code in the page.

 

[Lie Ryan]

If the user isn't currently signed in to our CAS, he'll be redirected to
the sign-in page and, after signing in, is returned to the page he
originally requested. The role decorator checks his privileges (based on
his CAS credentials) and either allows or denies him access. This adds
up to a LOT of framework-specific code that's been very easily factored
out. The CAS and role modules behind the decorators are, in turn,
generic frameworks that we've merely specialised for CherryPy. At some
point we'll get around to releasing some code.

In the end, it is the developer's responsibility not to write something
too tightly coupled with their framework, isn't it?
(or at least to minimize the framework-specific code to a certain area)

 

[Diez B. Roggisch]

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

 

[Martin Sand Christensen]

In the end, it is the developer's responsibility not to write
something too tightly coupled with their framework, isn't it? (or at
least to minimize the framework-specific code to a certain area)

That's a good summary of my point. However, I have very little
experience with other frameworks than CherryPy, so I do not want to draw
any general conclusions. My programmer's instincts say that it's true,
though.

 

[mdipierro]

Interesting post. I would like to make some comments about design
decisions that went into web2py:

- For each app Model/View/Controllers/Language Files/Static Files/
Modules/Cron Tasks are stored in separated folders
- You can code only the models (no controllers and no view) and you
get a fully functional admin interface
- You can develop only controllers (with or without models but no
views) and you get a fully working application with workflow
- There is a convention for dispatching. You can override it with
routes.
- There is no metadata in the framework. URLs are mapped into an app
(within the web2py instance), into a controller file, and into a
function (action) in that controller file.
- You can have multiple apps within a web2py instance (they can be
installed, uninstalled, packaged, compiled without restarting web2py)
- You can have multiple model files, multiple controllers and multiple
views. You can override the mapping between controllers and default
views.
- You can group files (models/controllers/views/static files)
functionally into plugins. Plugins can be packaged separately from the
app and applied to multiple apps.
- Plugins expose components (i.e. reusable objects that can be
embedded in a page and talk to their own controllers via ajax).
- Plugin components are coded as any other web2py models/controller/
view but the form submission is automatically trapped (transparently
to the user) and executed via ajax so that, if the component contains
a form only the component is reloaded upon submissions of the form.
- web2py supports FORM, SQLFORM, SQLFORM.factory and CRUD for
automtical generation of forms (from a model or other structure). All
web2py forms execute postbacks and modify themselves to report error
messages. A form is comprised of widgets that contain validators.
There is a default layout but it can be customized in the view by
allocating widgets or individual html tags.
- You can put doctests in actions and we provide a web interface for
testing the app online.
- It completely abstracts the database backend (we support 10
different database backends including Google App Engine) thus make the
code very portable.
- It authomatically writes sql for queries, for create table and alter
table.
-Web2py provides a Role Based Access Control mechanism with plugguble
login components so that you can authenticate using multiple mechanism
including Gmail and Twitter for example.

Specifically about you concerns:- better scalability
- easy to test => web2py is very easy to test because of the web based
interface to doctests
- easy to maintain => In web2py "Do not repeat yourself" trumps
"explicit if better than implicit". This means code is very compact.
- easy to re-use code for different applications => using plugins
- easy to migrate/port => because of DAL

Massimo

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