Ben Sizer wrote: > Paul Boddie wrote: > > Ben Sizer wrote: > > > > > > In my case, multimedia and game support is patchy, > > > > There are lots of multimedia and game frameworks for Python. Which ones > > have you tried and why are they insufficient? > > 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. > > Certainly, some Web frameworks have some element of Java flavouring, > > but there's also considerable diversity at least at certain levels. > > 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. > > Otherwise, no amount of complaining will put the > > two technologies together. > > 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 -- http://mail.python.org/mailman/listinfo/python-list