Ronald Oussoren wrote: >>1. Could we take the current bgen-generated C source and turn it over to >>manual maintainers? > >There's little change that this will be accepted in the official tree.
Since the official Carbon tree is largely moribund anyway, I can't say I'm too bothered by this. Hence my second suggestion of handling these extensions outside of the main Python distribution; an approach that's obviously worked extremely well for PyObjC, for example. I'm all for abandoning the original Carbon stuff to wither and die by itself: it's dug itself into a hole of its own making and I doubt anyone here cares enough to dig it out again on its own terms. It seems to me that the best bits stand a better chance of surviving and thriving as a third-party venture. Most likely an ad-hoc one as I've suggested: apart from anything else, there's a lot more folks who know C than bgen - and many hands make light work, as they say. Whereas constructing a brand new bgen replacement purely to rewrap a bunch of aging legacy APIs for which we already have plenty of C wrapper code simply isn't economically worthwhile. Sometimes the deliberately dumb solutions are actually the best. Like Bob says, Carbon has already passed the point of diminishing returns. These old Carbon APIs won't matter much in another few years anyway, so all we need to keep the still-useful bits comfortably ticking over in the meantime is one good initial cleanup of the existing C code and then maybe a handful of minor tweaks every 18 months or so. Which I'm pretty certain will be less work to do by hand than any other way. Use smart tools for rapidly evolving APIs like Cocoa and CF where the long-term benefits of investing in heavy automation are clear, and leave any odd maintenance jobs on existing legacy code to the manual code monkeys. Does that make sense? has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig