🌐 Mailman 3 December 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

Bad installer for wxPython2.8-osx-ansi-2.8.12.1-universal-py2.7
by Tony Cappellini Dec. 28, 2013

Dec. 28, 2013

I've just tried installing wx 2.8.12.1 on Mavericks and apparently the installer is bad. Has anyone else tried the installer for wxPython2.8-osx-ansi-2.8.12.1-universal-py2.7 ? When I run the pkg file a dialog tells me that that it is damaged. I've tried 2 mirror sites and 2 different browsers, all have the same results

2 2

Any Adobe CS/CC users in the house?
by Hengist Podd Dec. 18, 2013

Dec. 18, 2013

Just on the off-chance, will leave this here: http://www.mantasystems.co.uk/quickstart/ Requires some manual assembly, the current frontend UI is just a teeny touch old school, language documentation and tutorials are a couple months away, and GUI tools a bit further out still, but hopefully provides a taster of what I'm currently cooking up (in Python, natch). Cheers, has

1 0

py2app: argv emulation failing on OS X 10.9 Mavericks
by Brendan Simon (eTRIX) Dec. 18, 2013

Dec. 18, 2013

I have a python app that uses argv emulation with a custom url handler. i.e. when my url is clicked in a web page, it opens my app and passes the url as an argument to the app. My app works great on OS X 10.4, 10.5, 10.6, 10.7 and 10.8, but fails on 10.9 (Mavericks) :( No arguments are passed to the app. I'm use python 2.7.5 and py2app 0.7.3. Here's the issue on bitbucket. https://bitbucket.org/ronaldoussoren/py2app/issue/129/mavericks-osx-109-pro… Does anyone know what the problem might be and whether there are any fixes or work arounds ? Thanks, Brendan.

1 0