On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:I'm volunteering to keep improving PyObjC, but I won't promise that PyObjC will be complete enough to replace the Carbon tree by the time Python 3.0 goes into beta. Heck, just commiting the version of PyObjC that is in Leopard into a public repository took me three weeks :-(Which reminds me -- what version of Python is in Leopard?
2.5.1 + most of the patches that will be in 2.5.2 + some additional patches by Apple. AFAIK the latter are some patches to support their build machinery and patches that add support for DTrace.
Does anyone have suggestions on how to mobilize people for this without scaring them away when explaining what needs to be done?People, including myself to be honest, seem to find other things to dowhen the realize that fixing the Carbon wrappers involves working with and hacking on bgen :-(I admit bgen is too ancient and too ad-hoc to try and bother with (and I wrote most of it!). How would you solve the problem it solves today?
Bgen is pretty good at what it does, but it does have a very steep learning curve. It doesn't help that you have to be logged on as Jack on Jack's machine to regenerate the Carbon bindings, meaning that anyone else will have to do some work just to be able to *use* bgen.
I have a different code parsing tool for PyObjC, and AFAIK there is a another one that generates ctypes code.
On the bright side: Carbon is basicly dead: there will be no new development on Carbon and it also not supported in 64-bit mode (at least the GUI bits).
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
