🌐 Mailman 3 August 2013 - Pythonmac-SIG - python.org

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

New release of bdist_mpkg
by Matthew Brett Aug. 24, 2013

Aug. 24, 2013

Hi, I just did a new release of bdist_mpkg: https://pypi.python.org/pypi/bdist_mpkg/ The main new feature is Python 3 compatibility: https://github.com/matthew-brett/bdist_mpkg/blob/master/Changelog Thanks to Bob Ippolito for the original code and Ronald Oussoren for taking care of it. Please do let me know if you hit any bugs or misfeatures, Cheers, Matthew

1 0

py2app + pyqt: Differences between command-line and double-click
by Berg, Stuart Aug. 15, 2013

Aug. 15, 2013

Hi, I'm using py2app to packages my (cross-platform) PyQt app into a Mac OS X application bundle. (py2app is great, btw!) I was wondering if anyone could point me to some documentation that explains in detail how a python app bundle's launch process differs from launching the python app directly from the command-line. My app bundle seems to function exactly the same in most respects, but my main window doesn't activate unless I manually activate the application via command-tab. I give a few more details in this question on stack overflow: http://stackoverflow.com/questions/16574315/qt-mainwindow-does-not-appear-u… Any ideas, suggestions, or links would be appreciated. Thanks, Stuart

4 6