Bob wrote: >Nobody is suggesting that we manually wrap Carbon.
Indeed. However, given the effective deadlock that bgen is causing (great-in-theory being the enemy of good-in-practice) perhaps we could find a pragmatic compromise? A semi-automated system that works adequately would, I think, be preferable to a fully automated one that doesn't. 1. Could we take the current bgen-generated C source and turn it over to manual maintainers? Apple's Carbon APIs aren't changing much these days, so I doubt there'll be much need to regenerate existing extensions from scratch, and it'll be easier to find volunteers willing to apply bugfixes and minor addition by hand than via bgen. Copy-n-paste and C macros should be more than adequate for this kind of work. e.g. I'd be willing to fix and maintain the AE and OSA extensions by hand, whereas there's probably zero chance of finding someone willing to actively work on them via bgen. 2. Could we take the more useful Carbon extensions and create a new third-party 'CarbonX' package where they can be actively developed and maintained? The original Carbon extensions in the standard distribution could be quietly deprecated; a lot of it's just deadweight anyway. I can't see them being thrown out before Python 3.0, but we can discourage their use in favour of alternatives like CarbonX and PyObjC. has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
