About

Welcome to Panela, Matt Harrison's take on mostly Open Source, Linux, Python, innovation in those areas, other buzzwords and Dick Proenneke. It comes complete with the illustrations as needed. Note the opinions expressed here are merely my opinions and not the opinions of my employer.

about Matt

Calendar

««Aug 2008»»
SMTWTFS
      12
3456789
10111213141516
17181920212223
24
25
2627282930
31

My Top Tags

                                       

Mailing List

My RSS Feeds








Python web framework rewrite take two....

posted 2005.12.07 Wed
Is the ease of developing in python a drawback?  Is too much choice just confusing?

I'm in the middle of trying to get TurboGears working with Python 2.3 (the latest subversion head supposedly supports it...) to see if I can use it as a framework for SAM.  (Though like Titus, I'll probably just use CherryPy).  But it is suprising to hear of two more meta/mega web frameworks today:  Pylons and web.py.  So I guess python just makes it too easy to create your own framework... subway, django, TG...

Interesting that of the above mentioned frameworks they all have some overlap of their sub-components (Django being the notable exception that re-wrote everything).

Also interesting that ROR's outspoken creator, David, says if Django had existed a while ago he probably would've used it instead of creating his own framework.

For my needs I want to be able to expose web pages (and ajax endpoints) with a clear api, rather than using the php-like style in my latest prototype code.  Cherrypy should suit me fine.  And I can plug in whatever templating engine suits me (Cheetah, kidd, myghty, .... ).

As these mature, will there be consolidation, which tends to happen as things commoditize?  Will there continue to be more frameworks created as new people come to python and decide to scratch their itches to build websites?

tags:          

links: digg this    del.icio.us    reddit




1. Peter left...
2005.12.08 Thu 3:04 am :: http://www.peterbe.com

Judging from how web frameworks pop up like spots on a teenagers face, I suspect David "lied". He probably would have written his own thing being such a perfectionist as he is.

I'm wondering, why is there no buzz about zope3? Ok, it doesn't have a video or a well design website with AJAX but it's simple and yet technically much more mature and maintained by many more intelligent people (I'm unfortunately not one of them)


2. Matt left...
2005.12.08 Thu 3:45 am

Peter - We know that everything that comes out of David's mouth is pure truth. He wouldn't lie;) (Actually I think we need outspoken people like David to question the status quo...)

I haven't checked out Zope in 5 years. But when I did try it, it sure didn't feel like python. Using TG, Django and CherryPy feel very pythonic to me. Hopefully because a lot of these "Meta/Mega" Frameworks are using the same underlying components, even though effort is wasted in the glue there will be trickle down updates to the core componentry.


3. Kevin Dangoor left...
2005.12.08 Thu 6:34 am :: http://www.blueskyonmars.com

web.py doesn't appear to be so much a megaframework (at this point) as it is a reimplementation of a URL dispatch mechanism (ala Bobo, CherryPy, Routes, Paste/Wareweb, etc).

Regarding the megaframeworks and trickle down: Kid has been a big beneficiary of its place in TurboGears. David Stanek, in particular, came from TurboGears and has committed a whole bunch of useful changes. So, the effect is real.


4. Paul Boddie left...
2005.12.08 Thu 8:41 am

I won't lobby you intensively for WebStack's continued usage in SAM, Matt. ;-) That said, you might find my XSLTools toolkit moderately interesting for some of the stuff you want to do. Meanwhile, on the subject of web.py and its low-level wheel reinvention, it amazes me still that people like to write low-end stuff which only works with one or two technologies, and then hype it as the next Pythonic thing. Occasionally, I download various (mega)frameworks and take a look under the covers just to see how much work they've redone when they could have written against the WebStack API. Oh well...


5. Matt left...
2005.12.08 Thu 10:55 pm

Kevin- Thanks for that example. That is encouraging. I've seen that the TG mailing list is also frequented by the individual component authors, so having megaframeworks can help improve the low level stuff as well.

Paul- Do you have any examples of controller implentation (such as cherrypy) on top of WebStack? I want to have a pretty well defined api for letting end users add functionality. When you have jsp/php code it tends to get messy and not fun to maintain. Though I've also seen the opposite end of the spectrum with people layering so many technologies that it gets too complex. And I've also seen people who are supposed to program within the api of a framework but just ignore it, and that is probably the worst.

The idea behind WebStack is very compelling to me since I can understand that people might need to deploy their apps on different python app servers. Though for my needs, I'm pretty sure most deployments will be using the built in python webserver. I'll look into XSLTools... Thanks for the pointer.


6. Paul Boddie left...
2005.12.16 Fri 5:27 am

I'm afraid I don't have anything more than XSLTools working on top of WebStack, and I'm not totally sure that the supplied XSLForms toolkit has enough of a controller implementation in the style of something like CherryPy to be considered convenient for some people. Making stuff like CherryPy work on top of WebStack isn't really top of my list, I'm afraid, although I did write a compatibility layer so that Aquarium could use WebStack (although I really doubt how useful that is).


7. Ed left...
2006.03.30 Thu 5:47 pm

Just a little nit-picky comment, according to the page linked David said that he'd probably be using Django if he hadn't created RoR, while above it says he said that he wouldn't have created RoR if Django had been available earlier.

Actually, the implications are different, the first saying that Django would be the best substitute if RoR didn't exist, which still has an implication of RoR being superior. However, the second implies the availability of Django would negate any motivation to develop Rails, which would imply that Django is superior.

In any case, it's still a nice compliment by the creator of Rails.