A few particularly nice posts on the Python Web-SIG recently, in response to Ian Bicking's request for info from Python hosting providers.
First, Bill Janssen talks about how stable (pure) Python is for long-running processes.
Then Remi Delon writes about the multiple-package problem, and how every Python Web app uses some different mixture of 5-10 packages. It sounds like this wouldn't be so much of a problem for Remi if those packages weren't sometimes difficult to build, but this is a real problem for larger or less specialized hosting companies. After all, they need a fairly standardized install & upgrade that works across different people's applications!
It may be that WSGI adapters and the new 'egg' stuff will help with this... but this is an area where a Python CPAN might help.
Separately, I'm sure everyone saw this interview with Jonathan Rentzsch, but people may not have gotten more than 30 or 40 pages into it. There was some discussion of Python in there: here's a great quote from the middle.
... That said, my eye isn't on Java or C# to put the knife in Objective-C's back -- it's Python. Python addresses all the issues and PyObjC makes it easy to use Python with Cocoa. Indeed, PyObjC can do things Objective-C can't do by itself.
Of course immediately afterward there's the obligatory mention of how SLOW Python is, pushed by the interviewer. I dunno why this keeps on coming up; maybe people are trying to use Python for everything and running into speed problems that I haven't seen. Personally I use Python for whole-genome data crunching and speed is just not a problem.
More C++ book recommendations
A few days ago, I asked for good C++ books and got some good-looking recommendations. Ben Bornstein, a local friend who seems to periodically drop by this diary, just recommended two more: C++ Common Knowledge and Modern C++ Design. I already own the latter but never got into it; obviously it's time to give it a shot ;).
HTTP/SMTP libraries
OK, so clearly I was unclear...
Yesterday I asked about small HTTP/SMTP libraries. dfenwick suggested vmime, which is SMTP-capable. Jacob Smullyan also pointed out the obvious: neon, libwww, and curl. (He also pointed out the rather cool-looking SWILL, a system for driving non-Web apps via the web</a>.)
Of the four solutions suggested above, I like libwww the best, although it would encumber my distribution a bit because of the publicity requirements. ("This application uses...") But I really didn't explain why I needed this in the first place.
My primary bread'n'butter application is FamilyRelationsII, a GUI app written in FLTK that runs on Windows and OS X (well, and Linux too). I distribute it in binary form, primarily to biologists.
Unfortunately it occasionally crashes, usually via an assertion that I've put in there for sanity-checking reasons. Sometimes the assertion is caused by my stupidity, and occasionally it's caused by the genomic data. Either way, assertions happen. And whether or not it's an assertion, I want to know that it happened. And if it is an assertion, I want to get the assertion message and some associated information.
The intended user population is completely computer a-literate, to all intents and purposes. Moreover, the program is usually run from the Finder or the Explorer. This means that error messages usually don't get echoed anywhere, and even if they were saved to a log it'd be an uphill battle to have the user sent to me.
So I want the program to send it to me.
Hence SMTP/HTTP. I run a bunch of Web servers and mail servers, and I want automatic reporting to one of them. In particular, I want a thin library that can be entirely included in the source code; hence LGPL. I only need simple POST or sending capabilities, nothing fancy. I'd prefer to use a library that's smaller than my application, which is the problem with vmime and possibly the others (it may be possible to break libwww out into separate smaller pieces, where I can pick or choose what I want.)
Or, there might be an alternative solution... The only time I can remember seeing this kind of thing is with TalkBack, which lets mozilla.org know when your mozilla dies. Is there anything simple and automatic like this that doesn't require any user input?
thanks,
--titus