On 1 Apr, 2008, at 17:37, Kevin Walzer wrote:
has wrote:With the general de-Macification of Python 3.0 being planned, I wonder if the python3.0 interpreter should take the same approach, leaving itup to individual modules to decide if and when they want a GUI connection? Anyone any thoughts?What does the "de-Macification" in Python 3.0 mean? Will the Carbon modules be removed? I'm curious because the Python program I currently develop calls intoCarbon for a few things, and I'm mulling its future direction and design.
The current plan for Python 3.0 is to remove most of the mac-specific code
from the stdlib.The main reason for that is lack of maintenance, but IMO platform bindings shouldn't be in the standard library anyway because that makes it impossible
to adapt them to a changing platform in a timely manner. That is, even if the Carbon bindings were properly maintained we couldn't add Leopardbindings to the stdlib for Python 2.5.3 due to backward compatibility constraints.
I'd like to see Carbon bindings in PyObjC, especially the bits that weren't deprecated years ago, because some things can only be done in Carbon and not Cocoa. To be honest I don't know if that will ever happen due to lack of time
on my part. Ronald
-- Kevin Walzer Code by Kevin http://www.codebykevin.com _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
