[Pyobjc-dev] PyObjC plans for the near future

[Ronald O. <ron...@ma...>]

Hi,

I'll work on the following items in the nearish future:

(Mostly non-technical)

1) Migrate the repositories for PyObjC and py2app to mercurial with the repositories hosted on bitbucket

This gives two major advantages:

* a bugtracker that doesn't suck

* easier for others to prepare patches in private repositories

The hard part of the migration is not the technical migration itself, that's basicly just running 'hg convert' on the existing repositories but adjusting my workflow and making sure that I actually now how to work with mercurial branches.

2) Migrate all documentation to sphinx and flesh out the documentation

3) Rebuild the official website based on the sphinx documentation. I'll probably use my MobileMe account for that (with a custom domainname). The hard part of this is building a website L&F that I like, which means something different than the current website. On the technical side I can basicly reuse the current website management scripts with some fairly small adjustments.

(Programming related)

4) Work on properly testing py2app and related packages

I've started on this and want to end up with full test coverage to ensure that the tools work as intended.  Recent new features like support for pip-style namespace packages and relative imports were implemented after adding tests for them.

5) Add better support for setuptools to py2app

This will consist of two parts: (1) ensure that you can specify dependencies in the egg-files that should be satisfied before running py2app, either by reusing 'install_requires' or by adding a 'requires' option to the py2app configuration; and (2) add options for including whole eggs including meta-data into bundles.

6) Add a py2app_standalone command that can be used in Xcode templates

7) Ensure that all tests pass on the 2.3 branch of pyobjc and release pyobjc 2.3.1

8) Add code for making ObjC properties available as python properties (simular to objc.object_property, but for native properties)

9) Replace the code that looks for ObjC methods, replace the somewhat greedy searching code by a lazy scanner. That should
reduce memory usage and increase speed (both for initialization and for method calls)

10) Research a way to reduce the memory usage for the "bridgesupport" files

This will likely result in compiling the XML files into something more convenient and dropping the dependency on libxml.

I don't know in what timeframe all of this will happen, the list is longish and my time is limited. I do hope that I'll manage to release PyObjC 2.4 this year, but that is noted based on any kind of planning on my part.

In the longer run I'd like to experiment with a branch/fork of CPython that integrates PyObjC into the interpreter and replaces the memory management code by the Objective-C garbage collector, simular to what MacRuby does for ruby.  This would primarily help in reducing the remaining memory management problems (such as dealing with the weak-references used by NSOutlineViews), and may be a patch towards a Python interpreter without a GIL.    This is definitely something that will move forward very slowly, as it requires a significant amount of work.

Ronald

P.S. Please consider donating to PyObjC if you use it commercially. This can be done using the Paypal donations button on <http://pyobjc.sourceforge.net>.   Donations would help me find ways to spend more time on PyObjC, which would help moving the project forward faster.  Almost all work on PyObjC is done by me in my private time.