[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] PyGame Website Rewrite



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 <ndudfield@xxxxxxxxx> 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.