Thursday, January 23, 2003 | |
PyObjC continues to evolve rapildly. A news item was added that documents the changes since the 0.8 release. I have started to receive emails from folks who are considering using or starting to use PyObjC in production environments or for commercially targeted applications. While the documentation is lacking and there are still many items on the todo list, the core bridge is quite stable. There are bugs, but they are generally resolved very quickly. Furthermore, using Python as the development language for Cocoa apps is a natural fit. It feels right. Like Python, PyObjC features a set of unit tests that test most aspects of the core bridge and Foundation interaction. The AppKit is harder to test. Our tests are not as complete as Python, by any means, but the pyobjc test suite tests enough that the bridge can evolve rapidly with little risk that a developer is going to break everything. Let me rephrase that: Unit tests are critical to the success and stability of any API that will be used by many developers in diverse environments. Even unit tests that provide far less than full coverage will vastly improve project velocity while greatly reducing downtime related to fixing bugs that slipped into the release cycle. Knowing with absolute certainty that a particular change still leaves the codebase in a functional/useable state gives a developer confidence to push forward; to try new ideas with the comfort of being able to easily prove whether the idea works. Furthermore, unit tests provide an incredible source of knowledge. Unit tests provide a succinct and direct channel of communications regarding changes made to the project. The developer merely has to watch for changes to the tests to keep apace with changes made to the overall project. Unit tests are also a natural starting point for developers new to the project. The unit tests naturally reflect the architecture of that which they test and the implementation of the tests provide a wealth of information regarding the behavior of the APIs being tested, including what happens when the API is passed bogus arguments or otherwise fails. Back to PyObjC... Next up are Categories and Posing support. Neither are trivial, but we have some good ideas. Bridging of various API that take pointer types continues. NSRectFillList() was recently bridged. As a result, I was able to create a Hopalong fractal drawing app that renders about 115,000 points/second on a TiBook 667. Not bad, but room for improvement (though, at this point, most of the performance hit is in doing the math in Python).
I also have a PyObjC based personal project that should break some heads... |