On 1 Apr 2008, at 16:37, Kevin Walzer wrote:
> What does the "de-Macification" in Python 3.0 mean? Will the Carbon
> modules be removed?
See:
http://www.python.org/dev/peps/pep-3108/
I'm totally for their removal from the 3.0 stdlib, btw. They did their
job in the day, but they've long since become deadweight on Python
itself.
If backwards-compatibility becomes an major concern for some folks I
imagine they could rebundle the existing modules as a separate
distribution. IMO though it'd make more sense for projects that need
these modules to stick with 2.6, and for 3.0 users to kick off with a
completely clean slate. Not that many folks use the Carbon wrappers,
and a a lot of equivalent functionality is also available via PyObjC
which is fully and actively supported and obviously the way the wind
is blowing these days.
In future, I think the simplest thing will be to create ObjC wrappers
for any Carbon APIs you need, and access those via PyObjC. Such
wrappers would have the additional benefit of being usable from any
language with an ObjC bridge as well as ObjC itself, making them much
more economical to develop and maintain.
Incidentally, I'm already thinking of using objc-appscript to replace
the lower-level py-appscript APIs in 3.0, with just the high-level API
being implemented natively. e.g. See rb-cocoa-appscript in the
appscript svn repository for an idea of how that'll work.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
