Mailman 3 July 2014 - Pythonmac-SIG

PyObjC 3.0.1 on PyPI
by Ronald Oussoren Jan. 2, 2015

Jan. 2, 2015

Hi, I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself. All tests pass without problems, but there could still be problems. With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super. I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted). The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet. Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work). Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!). It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. Ronald P.S. I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-)

2 1

Re: [Pythonmac-SIG] [Pyobjc-dev] PyObjC 3.0.1 on PyPI
by Ronald Oussoren July 27, 2014

July 27, 2014

On 27 Jul 2014, at 15:49, Marc Van Olmen <marc(a)acclivitynyc.com> wrote: > hi Ronald, > > Thanks for you work and keep this project alive! > We shipped in July Checkout 4.0 with the pyobjc 3.0 of 2014-05-30. + Python 2.7.6 > > Q: > Any speeds ups mentioned here happened after that? Nope. Almost all that work happened early in 2013. > > Remarks: > So far the release seems stable the only issue we had was that since the latest upgrade to pyobjc 3.0 of 2014-05-30. + Python 2.7.6 > The startup time of our app was about 10 seconds longer. I haven't had the time yet to investigate what caused it but profiler indicated it was in gzip. > So I changed our packaging and distribute site-packages as unzipped and notice at 10 seconds startup speed up. > Hopefully in the coming months I have sometime to investigate what caused it. The metadata system may be at fault here, although it is supposed to be faster than before. Do you use “from Foundation import *”? It is highly advisable to avoid that because the framework wrapper modules lazily instantiate their contents and star-imports forces greedy initialisation. At least 3.0 should avoid the additional slowdown that was in 2.5 in the code that handles __all__. BTW. According to one of the talks at EP14 translating your source code using Cython could help in startup time. They started looking into Cython to get obfuscated code (to make it harder to reverse engineer their application) and noticed some performance improvements as well. That’s with plain Python code and no Cython-specific annotations. It would be cool to teach py2app to do this automatically and I have filed a feature request for that. I don’t know when I’ll get around to that though. The talk: https://ep2014.europython.eu/en/schedule/sessions/31/ (video and slides are available). Ronald > > best > > marc > > > > On Jul 27, 2014, at 5:00 AM, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > >> Hi, >> >> I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself. All tests pass without problems, but there could still be problems. >> >> With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. >> >> Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super. I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted). >> >> The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet. Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work). >> >> Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!). It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. >> >> Ronald >> >> P.S. I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-) >> ------------------------------------------------------------------------------ >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyobjc-dev(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev >

1 0

py2app 0.9 on PyPI
by Ronald Oussoren July 27, 2014

July 27, 2014

Hi, Now that I’m writing announcements anyway… I’ve also uploaded a new release of py2app. This release uses a new version of modulegraph that records more information about the links in the graph. This makes it possible to provide more interesting information on modules that py2app couldn’t find while building the app bundle: py2app now shows if a missing module was imported conditionally or not, and if it was imported as “from Y import mod” or “import mod” (the latter is more likely to be a real problem). This required some restructuring of the modulegraph code base, while the modulegraph unit tests are still not good enough. I think I’ve found and fixed all problems introduced by the refactoring, but I’m not 100% about that. There will be further refactoring, and test updates, in upcoming releases of both modulegraph and py2app. Ronald

1 0

Building compatible dependencies
by Chris Barker July 21, 2014

July 21, 2014

Hi folks, I know it'a at least theoretically possible to build libs under 10.9 that will work on 10.6 -- specifically compatible with the python.org python binaries. But I"m having trouble finding documentation of what flags you need. MACOSX_DEPLOYMENT_TARGET=10.6 should be required -- but anything else? personally, I've solved this by building on the oldest machine I want to support, but that's not always possible anymore. Anyone have an example? -thanks, --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

5 4

py2app & pillow
by Karsten Wolf July 21, 2014

July 21, 2014

Hi, in an py2app app I replaced the thumbnail mechanism from sips (via os.system) to Pillow. The resulting app size went from 11MB to 50 MB for the inclusion of the complete TCL/TK stuff. Is there an easy way to reduce that? Both, Python 2.7.6 and Pillow are compiled for intel 32bit on OSX10.6 -karsten

2 1