Ronald Oussoren wrote: > One thing we (Jack and I) talked about is moving at least the > Carbon modules to its own separate project instead of being part of > the standard library. The most important reason for this is that > the Carbon modules and Python itself should be on a different > release schedule: the Carbon should track whatever Apple is doing > instead of having to wait until the next major release of Python > before new APIs can be added.
Definitely. It also makes it harder to maintain the existing Carbon APIs, e.g. I ended up forking several Carbon extensions in order to fix and complete them for appscript, which isn't ideal. > A major stumbling block for that is that someone needs to step up > to commit to maintaining the thing. Furthermore, this stumbling block has a stumbling block of its own: bgen. There's very few folk around who understand it at all, and no documentation (AFAIK) for anyone else to make sense of it. Until there's some sort of decision made about bgen's future (maintain and document it? Replace it completely? Abandon it and maintain existing code by hand?), I can't see anyone really wanting to step into that tarpit. HTH has -- http://appscript.sourceforge.net http://rb-appscript.rubyforge.org http://appscript.sourceforge.net/objc-appscript.html _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
