Mailman 3 January 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

Installing/updating development py2app
by Brendan Simon (eTRIX) Jan. 31, 2014

Jan. 31, 2014

Hi py2app devs, A little while ago I installed py2app from development branch to test fixes on OS X 10.9. I installed with "python setup.py develop", including the other development modules that py2app complained about (version compatibility). My issue wasn't fixed, but looks like recent commits will fix the issue. I pulled the latest revision of py2app. Do I need to do "python setup.py develop" again ?? I did so, just to be sure. The problem seems to have been fixed or improved, but now my application crashes. I'm not sure if I need to update the other modules (altgraph, etc). Do I need to do that? Do I need to do "python setup.py develop" everytime ? What the best way, or recommend procedure, to try out new py2app commits ? Thanks, Brendan.

1 0

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 129, Issue 1
by Kevin Walzer Jan. 5, 2014

Jan. 5, 2014

On 1/5/14, 1:13 PM, Tony Cappellini wrote: > I'm going to install all my Python packages via macports- from now on. I > haven't checked if wx 3.0 is supported there yet or not. > I suspect not because it's too new. I also would like to stick with wx > 2.x- to avoid API changes. > > Can I just delete the wx installation folder to cleanly remove that old > wx installation, or is manual cleanup required? > > Thanks I'd run the "remove" script from the download I pointed you to--it will clean everything up. I'm sure you understand that using MacPorts for wx will require using their Python as well. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com

2 1

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 129, Issue 1
by Tony Cappellini Jan. 5, 2014

Jan. 5, 2014

---------- Forwarded message ---------- From: Kevin Walzer <kw(a)codebykevin.com> To: pythonmac-sig(a)python.org Cc: Date: Sat, 04 Jan 2014 22:51:23 -0500 Subject: Re: [Pythonmac-SIG] Bad installer for wxPython2.8-osx-ansi-2.8.12.1-universal-py2.7 On 1/4/14, 10:44 PM, Tony Cappellini wrote: > Ned Deily <nad(a)acm.org <mailto:nad@acm.org>> wrote: > > > sudo installer -pkg >>> /Volumes/wxPython2.9-osx-2.9.4.0-cocoa-py2.7/wxPython2.9- >>> osx-cocoa-py2.7. >>> pkg -target / >>> >> > > >>If you look at the version of wxPython referenced in the stack trace, it's 2.8, not the 2.9. one you installed. 2.8 is 32-bit >>only. Looks like Python is confused about which version to load. You may simply want to remove the 2.8 one altogether >>to avoid the conflict. If you look at my original post- I was referring to a wxPython 2.8 installer, that I have downloaded and suspected bad. When Ned Deily replied, he referenced a 2.9 installer for some reason. I have installed wx 2.8 using Ned's instructions (above), but substituting the path and filename to the installer in my original post. Now- to get back to a clean slate- if I just delete the wxPython directory that was installed, will that remove everything needed to cleanup, or are there other steps involved in removing a bad wx installation? Thanks

2 1

Re: [Pythonmac-SIG] Bad installer for wxPython2.8-osx-ansi-2.8.12.1-universal-py2.7
by Tony Cappellini Jan. 5, 2014

Jan. 5, 2014

---------- Forwarded message ---------- From: Ned Deily <nad(a)acm.org> To: pythonmac-sig(a)python.org Cc: Date: Sat, 28 Dec 2013 15:15:55 -0800 Subject: Re: [Pythonmac-SIG] Bad installer for wxPython2.8-osx-ansi-2.8.12.1-universal-py2.7 In article <nad-86DEA0.13454428122013(a)news.gmane.org>, Ned Deily <nad(a)acm.org> wrote: >>sudo installer -pkg >>/Volumes/wxPython2.9-osx-2.9.4.0-cocoa-py2.7/wxPython2.9-osx-cocoa-py2.7. >>pkg -target / Ok- thanks. This worked. I was able to run the installer- without problems. I do have one issue though. I am under the impression that "universal-py2.7" means it will run under both 32 & 64 bit systems. When I imported wx import wx Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/wxPython-ansi-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-ansi/wx/__init__.py", line 45, in <module> from wx._core import * File "/usr/local/lib/wxPython-ansi-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-ansi/wx/_core.py", line 4, in <module> import _core_ ImportError: /usr/local/lib/wxPython-ansi-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-ansi/wx/_core_.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode) I am using the default version of Python (2.7.5) that comes with Mavericks

2 1