> if you need Carbon, you stick with > 2.x, otherwise Py3K is requiring you modernize your Mac code and move > to Cocoa and PyObjC.
Brett, It's not just Carbon and Cocoa, which are primarily different bindings for developing Apple-style "applications", and primarily in my mind for GUI functionality (well, more than that, but primarily that -- QuickDraw vs. NeXTStep). There's a lot of really nifty non-GUI stuff on the Mac (heck, I do everything with X11 and GNU Emacs), and Python works particularly well there because it has bindings to some of that functionality. Those system libraries are largely C/C++ based, particularly in BSD userland, and seem to have differing levels of Objective-C wrappers. But these wrappers don't seem to typically provide the same functionality that the C API does, particularly for Core Foundation, which is a collection of C APIs. http://developer.apple.com/documentation/CoreFoundation/index.html The "plat-mac" stuff is a mix of GUI and "application" things, which I agree have been largely superseded by PyObjC, and "internals" things, which have not. So it needs some sorting. Maybe on the Mac-SIG mailing list? Maybe send out a message there saying, "We intend to jettison plat-mac for Python 3K because PyObjC makes it unnecessary", and see if anyone objects. Personally, I think it makes sense to replace the existing undocumented plat-mac non-GUI modules with documented ctypes-based modules. I don't develop Apple-style applications (or at least, not in C or Objective-C), thus I don't use either Carbon or Cocoa much, so others may have more information on this. Bill _______________________________________________ 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
