🌐 Mailman 3 January 2015 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] [Pyobjc-dev] Moving PyObjC and py2app forward
by Chris Barker Feb. 2, 2015

Feb. 2, 2015

On Thu, Jan 29, 2015 at 10:20 AM, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > I’m not sure how to make serious progress with my current load (both work > and privately). Does anyone have experience with crowd-funding for > open-source work? > > > I guess not. I’m still interested in idea’s on how to improve > development/support for PyObjC. > I sure don't have any experience with crown funding. But are you saying that you could put time into it if you could get paid? Maybe kick starter? thought this: http://blog.felixbreuer.net/2013/04/24/crowdfunding-for-open-source.html indicates that it doesn't work well for Open source projects. Are you set up with a consultancy so that people could pay you for a particular bug fix or feature? For example, the US federal government (which I work for) can not donate to anything. We can, however, pay a contractor to provide a particular service. As an example, we are right now wrestling with PY2App to distribute a product. If we could have hired you to get that all set up for us, then you may have been able to get a few bugs fixed, while we could have gotten what we needed to economically. NOTE: it's too late now, and It might have been difficult for us to contract with a non-US entity, but you get the idea. As a matter of fact, we did something much like this with Robin Dunn, the wxPython developer -- we hired him to extend an app of ours that required some updating/improving of wxPython. -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

2 1

Re: [Pythonmac-SIG] [Pyobjc-dev] Moving PyObjC and py2app forward
by Ronald Oussoren Jan. 29, 2015

Jan. 29, 2015

> On 10 Dec 2014, at 23:11, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > I’m not sure how to make serious progress with my current load (both work and privately). Does anyone have experience with crowd-funding for open-source work? I guess not. I’m still interested in idea’s on how to improve development/support for PyObjC. Ronald > On 10 Dec 2014, at 23:11, Ronald Oussoren <ronaldoussoren(a)mac.com> wrote: > > Hi, > > ’Tis the time to be contemplative, and I’ve been thinking a bit about PyObjC, py2app: what I’d like to do with them, and how much time I have to work on them. Things don’t quite add up because there’s a lot more that I’d like to do than I expect to be able to do in any reasonable timeframe. > > In no particular order (and far from complete): > > Finish work to add metadata for APIs introduced in OSX 10.10 and 10.9 (update existing framework wrappers and add new ones where appropriate) > > It should be pretty straightforward to add metadata now that objective.metadata is based on libclang (thanks to James Ranking). It is however still a relatively large amount of work because it is necessary to manually check which APIs require manual additions to the metadata, and because I prefer to add unittests for the framework wrappers because those have caught a fair amount of problems in the past. > > Python 3.4 adds an “asyncio” library (with backports on PyPI). It would be useful to add a pluggable event loop that integrates with Cocoa’s runloop (NSRunloop and CFRunloop), and furthermore it would be interesting to see if the tasks and coroutines from asyncio can be used to simplify Cocoa code: any Cocoa code with a “completionHandler” argument block might give nicer python code when used from a coroutine. > > That is, instead of something like: > > def onCompletion(result): > # … > > anObject.runTaskWithCompletionHandler(onCompletion) > > you’d get something like: > > result = anObject.runTask() > # … > > There needs to be a significant example of how to write a GUI without using XIB files. > To expand on the previous item: there needs to be a non-trivial example for writing a GUI with PyObjC that addresses issues one commonly runs into with writing code (aggressivly catch python exceptions before they cause problems in Cocoa, …). This can be used to enhance PyObjC itself: instead of adding work-arounds for odd behavior try to address the root cause. > > It’s time to try to refactor py2app into a library that does the work and a setuptools extension for the API. There are two reasons for that: this gives us a fighting chance to add useful unittests (py2app’s tests currently are primarily slow integration tests), and secondly this would make it a lot easier to design a modern interface that doesn’t rely on setuptools (using a declarative configuration file, …) > > py2app currently doesn’t support code signing, setuptools metadata, adding entire eggs/wheels and more. All of those are more and more necessary to ship the output of py2app outside of a controlled environment and AFAIK a number of py2app users work around the lack of those features by adding pre- and post-process scripting around py2app. > > Both py2app and PyObjC need significant work on their documentation. The documentation for py2app is minimal enough to make it effectively non-existing. > > PyObjC and py2app need some form of CI, especially for supporting platforms and libraries I don’t use regularly myself (for example OSX 10.6 support in PyObjC and support for PyQt in py2app). Something like Jenkins or buildbot could work, but setting up the infrastructure requires effort. I currently have to manually test, and due to lack of time I rarely run on older OSX releases and that seems to have resulted in breakage (for example issue #100 on PyObjC’s tracker). > > I’m not sure how to make serious progress with my current load (both work and privately). Does anyone have experience with crowd-funding for open-source work? > > Ronald > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktr… > Pyobjc-dev mailing list > Pyobjc-dev(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

1 0

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