[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] PyGame Website Rewrite
> I do not know anything about cherrypy, so here're some relevant
> questions for both frameworks:
>
> * How good is the integration of a wiki solution and maybe bug tracking
> system without implementing it ourselves?
> * How good is the integration of other components, which might be
> necessary in the future?
> * How much effort has to be put into it to add new features? Is it just
> about adding/enabling a component or writing a whole bunch of code?
> * What is the key difference between cherrypy (denoted as HTTP
> framework) and Django (web framework)?
>
>
I have a little bit of experience with CherryPy and a tiny tiny bit of
experience with Django. Here is my 2.0 cents.
A while back I read a considerable amount about python frameworks before
choosing CherryPy
I say I chose CherryPy but that wasn't really the case. That choice was
made for
me. I did however choose further components to extend CherryPy with after
becoming frustrated with `raw` CherryPy and a `raw` DB2 api.
Making pages by concatenating strings is horrible and very resistant to
change.
You really want a templating system of some sort where you can integrate
designers changes nicely or have them do it themselves (concurrently)
You also want to be able to apply any special features your editor has for
editing html. Even PHP is better in this respect than `raw` CherryPy for
anything beyond a `Hello World` toy site.
Enter overwhelming array of choices. Then you have to find a way of
integrating
the templating system with CherryPy.
You'll find you want an ORM/query builder soon enough as writing your
own (again
using string building, you just want a small simple one) proves to be
distracting. Any time you want a feature requiring something beyond your
home-
baked lib you have to code something up and write tests for it.
Form handling? Do you want to write a form validation library? No? Spend
some
time searching for a good one *with a future*. Pagination? Email? I
literally
copy/pasted then modified the code from Django for the latter two.
In short, you end up writing an ad-hoc glue framework on top of
CherryPy. With
just one person working on it, you can get away without writing a heap
of tests
and documentation. With multiple people working on it you'd really need
to to
make sure everyone is on the same page.
Choosing CherryPy won't just be a matter of choosing it and running with it,
it'll also be a matter of choosing more components, how to integrate
them and
documenting it.
An advantage of doing it this way, not to be understated, is that you'll
learn
how to use those components individually and can apply them elsewhere.
From what I have read, each of the components in the Django stack have
superior
respective stand alone alternatives.
eg Django ORM is almost univerally agreed upon to be inferior to SQLAlchemy
Peronally I have used this stack for a few sites:
Request/Response/Server: CherryPy
ORM + Query Generator: SQLAlchemy
Form Handling: FormEncode
Templating: Genshi
Image Manipulation: PIL
If I needed to learn TurboGears 2 or Pylons for some reason then I'd already
know many of the pieces. SQLAlchemy, FormEncode, Genshi.
If I need to use database access for anything then SQLAlchemy is very
useful.
You can introspect existing databases easily and then just define the
relations
with a few lines of code. ( sqlalchemy.ext.sqlsoup ) If you define your
schema
in python then you can automatically build the tables to whatever
database you
like. SQLLite is useful for in memory test databases.
If I wanted to for some reason create dynamic and perfectly valid xhtml
based
documents( say for converting to pdf format with Prince XML) then Genshi
would
be hanging at my toolbelt. If I want to make a TRAC plugin I know how to
use its
templating language. (The main TRAC developer also designed Genshi )
CherryPy itself has a Tool system for integrating third party components
and for
abstracting code into reusable `filters`. Builtin Tools include unicode
codecs,
gzip encoding, json encoding, header modifiers and the like. It has
quite a nice
configuration framework supporting multiple deployment environments and
allows
you to target filters right down to the exact page handler. It is a great
foundation to build upon with many points of extensibility. Pure WSGI (which
CherryPy fully supports) is less granular as far as `middleware`.
However you *will* end up having to create a framework, whether it be
consciously written or it just evolves naturally from factoring out
duplicate
code. Needless to say, the first attempts will be pretty horrible. This,
on top
of writing the actual site.
The potential advantage to Django is that you are walking a well
travelled road
and it is well documented. And as it's a full stack framework all the
documentation is in one place, likewise with the `community`.
The #django irc channel almost rivals #python in terms of numbers. It is not
uncommon to see 600 people. In contrast #cherrypy will, anecdotally, have on
average 35 people.
Taking a *simplified* look at the python web world (leaving aside the Zope)
there is basically Django and the others. The others are basically split
into
the CherryPy camp and the `pure` WSGI camp. The WSGI camp which includes
Pylons
and Turbogears, the two biggest players behind Django, outnumbers
CherryPy in
terms of users.
If you don't know what WSGI is: http://lmgtfy.com/?q=wsgi+python
See http://www.cherrypy.org/wiki/CherryPyAndPaste for CherryPy's head
architects
comparison between CherryPy and Paste. Paste has most of the mindshare
of the
WSGI camp. Obviously he is biased but you can see where he is coming from.
This was written around the time the TurboGears community was deciding
to base
their framework no longer on CherryPy (version 2) but instead on
Paste/Pylons.
Oh and Paste has since started morphing into WebOb. Things change a lot...
CherryPy 3 is quite a different beast to its previous version and apparently
addresses a lot of the problems the TurboGears users had. An example of how
having many users drives forward development.
CherryPy is IMO (salt nugget: never actually *really* delved into other
frameworks) a superior more flexible technology but it is in the minority in
terms of userbase so the core has less bug finders and contributors. It also
means less people to help with potential problems. Less books written
and being
written about it. Less HOWTOs. Less mailing list subscribers. You will
be `using
the source` quite often.
FWIW Here is a rundown of people in irc channels at this point in time.
Python at large:
#python 683
Django School:
#django: 552
#pinax: 56
WSGI School:
#pylons: 102 (Mako templates irc)
#turbogears: 53
#pythonpaste: 21
Independents:
#cherrypy: 38
#sqlalchemy: 88
#python-genshi 15
Probably you'll have more potential contributors/maintainers using
Django. You
get a lot of guidance and free documentation with Django. Lots of Django
`apps`.
Things like finding editor support (Syntax highlighting / Code Snippets) for
Django templates I'd imagine would be very easy.
There is also an interesting project based upon Django pulling together
a heap
of reusable django `apps` called Pinax. See http://pinaxproject.com/ No
idea how
well it really works though going by the nubmers in the irc channel it is
gaining some traction. I remember watching a recorded presentation on it on
google video at some point and thinking it sounded pretty nifty.
After all is said, it looks like it is going to be a lot of work redoing the
site.
If most of the people that are motivated to do the work already have
experience
with Django I think it would just be more work for all involved using a
custom
CherryPy stack.
Contributors would have to follow the evolving `framework`. They'd have
to spend
time documenting it if they wanted to make it easy for more people to
contribute. They'd likely waste time arguing over the best ways of doing
things
and which components to use. Would it ever get done? Or would everyone
just get
sick of it?
For an opensource project with potentially quite a few people working on
it (The
more the better right?) then I'd say Django would be a good fit due to the
`free` unified documentation and resources surrounding it and the fact that
every one is on the same page.
Having never *really* used django but having read peoples criticisms the
only
hesitation I'd have in using Django is that it may not be flexible
enough to do
exactly what people want it do.
I can't see anything on the existing page that wouldn't fit inside Django's
*claimed* paramaters of operation though. The site isn't likely to need
database
sharding?
I have only done a few fairly simple sites with CherryPy and never got past
setting up the auto-admin with an old version of Django (0.96 svn).
Having said that I'd imagine if you worked within Djangos parameters (?)
you'd
have a nice site up and running quicker than using CherryPy and have a
larger
pool of potential contributors/maintainers.
For personal projects where you want total control I'd learn CherryPy
(and other peripherals)
for reasons mentioned above. It is a very flexible base to build upon.
It's a shame there
isn't more people using it as there would be more off the shelf components.
It would probably pay to actually hear from someone who has used both to
build
real sites and not just toy ones.