Frameworks

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Mon Oct 19 04:24:34 EDT 2009


flebber a écrit :
> Hi
> 
> I have been searching through the vast array of python frameworks
> http://wiki.python.org/moin/WebFrameworks and its quite astounding the
> choice available.
> 
> I am looking at using a web framework for my personal project which
> isn't actually aimed at developing a website as such. However I deduce
> that rather than creating a gui application and screen input for data,
> I can use a web browser for this and have a great array of tools to
> format input screens and output display formats.

Yeps - but remember that a web app will have a couple limitations / 
drawbacks, specially wrt/ handling complex UI.

> Since I will be retreiving information from several websites (usually
> csv files) formatting them and submitting them to a database and
> creating queries and printouts based on them most frameworks seem to
> handle this basically with ease and for any complex queries most
> support SqlAlchemy.
> 
> Is it simply a case of just picking one and starting and I would find
> it hard to be dissapointed or is there a few special considerations to
> make, though I am unsure what they are?

Given your "specs", forget about monstruosities like Zope, Twisted etc, 
that will mostly get in the way. You have simple needs, use a simple 
tool !-)

> Most obvious ones I am considering are Django (Of course),

A pretty good framework, but you'll loose some of it's nice features if 
you ever want to use an alternate DB layer or templating system. OTHO, 
most other more "flexible" frameworks just don't offer this level of 
integration, so it's may not be such a big deal.

Note that Django's ORM, while already pretty good and constently 
improving, is not as powerful as SLQAlchemy (now nothing prevents you 
from going down to raw SQL for the more complex queries - and this might 
be better anyway, since complex queries usually requires to be very fine 
tuned and tend to not be really portable). The Forms API OTHO is a real 
winner IMHO.

> Pylons
> includes SqlAlchemy, Sql Object and templating and I here turbogears
> plans to sit on top of this platform.

I admit I fail to see what TG brings except for more indirection levels.

> Zope I am considering but I am a
> little confused by this.

Friendly advice (based on years of working experience): don't waste your 
time with Zope.

> The are heaps of others but not sure how to
> narrow the selection criteria.
> 
> How/Why woul you split Django and Pylons let alone the others?

Django : very strong integration, excellent documentation and support, 
huge community, really easy to get started with. And possibly a bit more 
mature and stable...

Pylons : more loosely coupled (imply: less integration), based on 
"standard" components - which is both a blessing and a curse, specially 
wrt/ documentation -, requires a good knowledge of Python and the HTTP 
protocol to get started with. Very powerful and flexible but this comes 
with a price...

Now both are written by talented programmers, and both are pretty good 
tools. I guess it's more a matter of personal preferences and/or 
external constraints (PHB etc...) than anything else.

A couple other "lightweight" candidates you migh want to consider are 
werkzeug and web.py:

http://werkzeug.pocoo.org/
http://webpy.org/

> Database likely to be MySQl

Mmmm.... If your application is "write-heavy", PostgreSQL might be a 
better choice. Anyway, both Django's ORM and SQLAlchemy work fine with 
MySQL AFAICT.



More information about the Python-list mailing list