Mailman 3 September 2013 - Pythonmac-SIG

Towards PyObjC 3.0
by Ronald Oussoren June 3, 2014

June 3, 2014

Hi, I recently realised that I've been much to silent on the development of PyObjC. I'm making steady progress on a new major release of PyObjC and am getting closer to a beta release of PyObjC 3.0, although progress is too slow to my taste :-) In januari (6 months ago already...) I was at a hackweek @Dropbox where I seriously started work on this new release. During that week I basicly rewrote the way that PyObjC looks for methods, the old way was inherently ugly and slow, the new one is cleaner and faster (although it appears to be not so much faster that its actually noticable...). That rewrite probably wouldn't have happened without hackweek, it required several days of concentrated hacking and that is something I can't do in my regular environment (there's those pesky customers that also want to get work done). Since then I've done further cleanup work and some optimization (first tests indicate that the bridge uses less memory and is faster). I'm finally closing in on a situation where the core bridge is cleaned up and can be reasonably sure that I won't have to make backward incompatible changes in the future. Now up to the really hard work: clean up the documentation and example code. That will probably eat away a lot of nights (with a lot of simple changes in the examples and hard thinking on how to improve the documentation; writing usable documentation is hard). My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further. Currently side-tracked on trying to get a change to super() into Python 3.4, Ronald P.S. A small public service announcement: try to avoid "from Cocoa import *", and use explicit imports (either "import Cocoa; o = Cocoa.NSObject.new()" or "from Cocoa import NSObject"). The current release of PyObjC contains optimizations that make explicit imports faster by doing much less work, and I expect to improve this further in future release. A nice side effect of avoiding '*' imports is that code analysis tools like pyflakes will do a much better jobs on your code.

3 3

avoiding system's "easy-install.pth" with custom distribution
by Nat Echols Sept. 13, 2013

Sept. 13, 2013

I'm distributing a large cross-platform Python-based application, for which we bundle Python 2.7 and a number of dependencies (wxPython, matplotlib, etc.). We've tried to make it as self-contained as possible, to prevent either a) polluting the user's environment and potentially breaking other programs, or b) breaking our program because other software pollutes the environment. This means wiping out PYTHONPATH at runtime, which has worked quite well for us. What I've now discovered is that at least on OS 10.7.5, if a user installs packages for the system python using easy_install (possibly other mechanisms as well, but that's what "worked" for me), these will now end up in the search path for our app's python interpreter, and override many of the packages we distribute because they appear relatively early in sys.path. The problem appears to be traceable to this file: /Library/Python/2.7/site-packages/easy-install.pth which modifies sys.path directly. Removing or renaming that file leaves our custom distribution's path alone. So, two questions: 1) Why is this happening? It seems incredibly broken - but I have no idea who's fault it is, for all I know we're doing something foolish when we compile Python on our build system (10.6, if it matters). 2) Is there any way we can modify our distribution to avoid this? thanks, Nat

4 4

Python 3.4.0 alpha 2 available
by Ned Deily Sept. 9, 2013

Sept. 9, 2013

I would like call your attention to the latest alpha release of Python 3.4.0 and a new batteries-included feature for OS X users. For 3.4.0.a2, the python.org 64-bit/32-bit installer now includes its own private version of Tcl/Tk 8.5.14 so it is no longer necessary to install a third-party version of Tcl/Tk 8.5 to workaround the problematic system versions shipped in OS X 10.6+. Unlike Pythons from previous installers, only this private version will be used by tkinter and IDLE. It will have no effect on or be affected by any other versions of Tcl/Tk installed on your system, such as ActivelTcl 8.5.x or Apple 8.5.x. Since this is a new feature and somewhat experimental, it may change prior to the official release of Python 3.4.0, planned for 2014-02. There will be other OS X installer-related changes coming. Please report any problems or issues you encounter to the Python bug tracker. Thanks! http://www.python.org/download/releases/3.4.0/ http://www.python.org/download/mac/tcltk/ http://bugs.python.org -- Ned Deily, nad(a)acm.org

1 0