Mailman 3 March 2014 - 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

Utility to copy dynamic libs into OSX wheels
by Matthew Brett March 26, 2014

March 26, 2014

Hi, I just released a first very alpha version of a utility called 'delocate'. It analyzes code in a wheel for any missing dynamic libraries, and copies these into the wheel: https://pypi.python.org/pypi/delocate For example, something like: delocate-wheel scipy-0.14.0b1-cp34-cp34m-macosx_10_6_intel.whl will find the non-system dynamic libs that the wheel needs, and copy them into the wheel, fixing the links as it goes. This can make it easier to release wheels that will work across machines. I'd be very grateful for feedback... Cheers, Matthew

2 1

webbrowser uses osascript instead of open
by mk0423＠towb.de March 16, 2014

March 16, 2014

Hi, why does the webbrowser module use bin/osascript instead of bin/open? Seems more complicated, and both support launching browsers other than the default.

2 1

linking extensions for older builds with newer pythons...
by Chris Barker March 7, 2014

March 7, 2014

The numpy folks are trying hard to get binary wheel sup on PyPi yeah! But this brought hup an issue -- PyPI policy is that binary wheels should be built for the python.org binaries -- which is great. The Python.org binaries are built for >=10.6, 32+64 bit Intel, and have the platfrom name: 10_6_intel All is well and good. The complication: The Apple builds of Python presumably use the newer SDKs, and have platform names like: 10_7_intel the 10_7 does not match the 10_6, and thus pip will not install the binary. If you re-name the wheel, then pip happily installs it, and it seems to work fine. So there is a pull request for a patch to the tools to support >=10_6, rather than =10_6 -- so that packages built python.org build will also be installable on newer builds. This has worked for years with numpy and others (and now that I think about it, wxPython has binaries that work on python.org and Apple's build.) So is it officially supported to link a *.so built against a older SDK to a application buit with a newer SDK? If so ,then this seems a nice convenience for the MAc crowd. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

3 3