Ben said:
PyGame was barely maintained for a year, and is based on SDL which was
also barely maintained for a year, and which hasn't kept up with
hardware advances at all. On the graphical side you can opt for OpenGL,
the Python library for which is also barely maintained (though I hear
work is underway behind the scenes) and doesn't provide much more than
a minimal layer over the C interface anyway. DirectX support only
appeared this year unless you used IronPython, and it doesn't seem very
popular.
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.
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.
Which other frameworks are you thinking of? I know of a variety of
wrappers around individual libraries, and of wrappers around 3D engines
such as Irrlicht and Ogre, but not much else.
If I were to consider other three-dimensional rendering technologies,
I'd probably look at things like Soya 3D, Panda3D and whatever other
people have dug up:
http://www.vrplumber.com/py3d.py
You also mentioned multimedia frameworks, and this is probably another
area where there are so many projects that it's hard to pick the good
ones.
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.
Since that time, WSGI has emerged as an interoperability technology,
but the fundamental platform fragmentation issues remain, as everyone
attempts to show how easy it is to write "WSGI middleware". Moreover,
the server abstractions required by widely-deployed applications are
still necessary, and it is in precisely this area that framework
proliferation has occurred.
There are probably some hosts that will provide
shared hosting for your Django or Turbogears app, but they are not
exactly numerous. The barrier to entry here is much higher than with
PHP or ASP, for example.
I think the attitude has been that if you're not willing to lay out the
bucks (albeit not quite as much as it used to be now that virtual
private servers are becoming commonplace), the big players in the
frameworks scene aren't willing to pay you much attention. But as
applications like ViewCVS show, many people appreciate Web application
deployment on low-end hosting, and that not all Web applications are
part of some big Web 2.0 rollout.
And even with the full framework approach, the
field has been so fragmented until recently that in terms of community
support, you'd be better off opting for another language. I appreciate
there's a diversity vs. standardisation argument there which may never
be settled, so I accept this is just a personal opinion, but I do think
a critical mass of users is important with any technology.
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. The consequence of that
decision has been a slight, one centimetre upward movement of the
Python Web scene's "healthy competition" in the entire "framework
stack".
I'm in a similar situation to the original poster; I'd like to use
Turbogears for an app I want to write, but will probably end up doing
it in PHP instead, because I can't get dedicated hardware or a local
host for Turbogears. (Never mind the lack of documentation.)
Sorry to hear that! This point was probably raised a while ago on the
Web-SIG mailing list, and if you're bothered, I'm sure you can track
down whatever reasoning was put forward for the neglect of this
particular usage situation throughout the major frameworks.
It's a fair point, but on the other hand, saying "if you want it doing,
do it yourself" doesn't objectively improve the status quo. If
something doesn't exist, it doesn't exist, and it's valid to comment
upon that fact.
Well, returning to the original point, Oracle database modules have
existed for more than ten years and are presumably a mature area now.
Meanwhile, Django seemed to favour PostgreSQL as an RDBMS last time I
checked. All it takes is someone to stick their neck out and finish the
job - an activity which can admittedly seem suspended for years,
considering the varying levels of support for different database
systems in Webware's MiddleKit persistence layer over its lifetime.
Paul
