Hi,
very detailed emails from Marcus and Nicholas...
a few related points below.
I'd be interested in knowing what jug, and orcun think of using Django?
Also what they think of a cherrypy based stack?
Also, what are the preferences of Lenard, Devon, pymike, and anyone else who
is interested in contributing? Please state the level of commitment you're
willing to make, and also which option(s) you'd be happy using.
- The main author of cherrypy(Robert Brewer) said he'd help us with any
major issues we had, and so did some other cherrypy mailing list people.
The cherrypy mailing list is also more active than the pygame one, so I'm
sure we won't have any issues with docs or help.
- documentation is extensive for cherrypy(it's a 10 year old project, in
it's third generation).
- we would have to choose a stack. The stack Nicholas mentioned seems
pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy +
pygame of course for imaging... and joysick control of the website. So
that is the stack we would be chosing.
- cherrypy code seems cleaner... as it's just python objects.
class MySite(object):
def index(self):
return "hello world!"
def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)
index.exposed = True
news.exposed = True
This creates these urls by default:
/
/index
/news
/news/10
/news?id=10
- cherrypy has less code compared to django, and is changing less.
- django is usually run using apache modpython or mod_wsgi, or even with
cherrypy(or other wsgi server). They don't recommend using the bundled
django webserver. Whereas cherrypy is considered one of, if not the best
python web servers. With cherrypy you use the same webserver for
development, and for production.
- you can run cherrypy inside a pygame application. Cherrypy doesn't
control the main loop if you don't want it to.
- there are more wsgi components than there are pinax apps. Also pinax apps
should theoretically be able to play with wsgi. I'm pretty sure you can use
django apps as wsgi components now too.
On Sat, Apr 25, 2009 at 3:51 PM, Nicholas Dudfield <ndudfi...@gmail.com>wrote:
>
> > 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.
>
