Need a compelling argument to use Django instead of Rails

[Ben Sizer]

Paul Boddie wrote:
> I can only profess familiarity with Pygame which still seems to do more
> or less what it always did, although I haven't kept up with the
> community, but I have recently released a simple game which seems to
> work quite well. By "simple", I mean two-dimensional playing areas,
> pre-recorded soundtracks, retro-style gameplay.

PyGame is great at what it does, which as you say, is usually
retro-style 2D games. It also provides a reasonable way of setting up a
window for input, sound mixing, etc. But its 2D technology is primitive
(eg. DirectDraw 6 on Windows if I remember correctly) and much of the
rest is not very advanced, such as limited support for controllers,
extra mouse buttons, 3D sound, etc. This is more a limitation of SDL
which got neglected in recent years.

Even C++ comes with OpenGL in the standard library. I am disappointed
that this hasn't become the case with Python. I don't even know if
PyOpenGL is compatible with the latest incarnation of NumPy or whether
you have to rebuild it all yourself. It's a bit of a mess really.

> If I were to get into OpenGL, I'd look at stuff like PyQt alongside
> other traditional bindings, mostly because such frameworks - certainly
> Qt, as far as I've seen from various reports - usually incorporate a
> lot of effort resulting from a serious amount of developer attention to
> integrating such technologies and making them work reliably in a number
> of environments.

Does PyQT play well with PyGame? And isn't it more of a windowing
environment?

> > Pretty much every Python web offering revolves around you having your
> > own server with the luxury of running your own long-running processes
> > on it. Great for business apps, not much use for the hobbyist or
> > independent site.
>
> Once upon a time I used to advocate my WebStack framework as a solution
> to this problem situation: WebStack applications run on BaseHTTPServer
> or other monolithic servers (Webware, Twisted, Zope 2, Java Servlet),
> but can also be deployed as CGI or in mod_python environments. The
> apparent response to this advocacy (which was backed up by an actual
> implementation) was that no-one needed such flexibility: an opinion
> somewhat at odds with actual practice if you consider widely-deployed
> applications such as ViewCVS/ViewVC, Trac, MoinMoin, and so on, where
> all of these have provided their own server abstractions at least until
> very recently.

Of course, if you're a developer producing your own framework - as
pretty much everybody on the Web-SIG was - then you're presumably
already aiming at the dedicated hosting space, so it's not surprising
that such flexibility is not held in high regard by those.

> I've said this a few times now, but it's worth repeating: when WSGI was
> proposed as the next great thing in Python Web standardisation (a topic
> in which no-one had any substantial interest until PHP/Ruby were
> considered ahead of Python in certain much-discussed decisions), it was
> formulated in such a way as to stay off the turf already occupied by
> the significant Python frameworks of the time.

This is something I wasn't incredibly happy about, as I felt it meant
that personal egos were being saved at the expense of improving Python.
And I always thought that WSGI was solving the wrong problem. It
certainly didn't go very far towards meeting the expressed goals of the
Web-SIG. Oh well.
<http://mail.python.org/pipermail/web-sig/2004-August/000650.html>

-- 
Ben Sizer