Re: [Pyobjc-dev] Achieving 1.0....

[Ronald O. <ous...@ci...>]

On Tuesday, Oct 22, 2002, at 07:25 Europe/Amsterdam, Bill Bumgarner 
wrote:

> [This is not a request to do a 1.0 release without an official interim 
> release -- just some planning for the real live 1.0]
Speaking of interim releases... Now that people are getting interrested 
in PyObjC it would be better to get one out sometime soon.

>
> In the interests in achieving a 1.0 release, I thought I would take a 
> very brief moment to toss out some ideas of what the project needs to 
> get there.
>
> ---
>
> First and foremost, we need a unit testing suite that provides 
> complete coverage for the modules features.  As it stands, I keep 
> stepping on Ronald's toes and he keeps stepping on mine -- once we 
> work through the issues, the end result tends to work everywhere, but 
> the interim is a pain for both of us.  This is largely because Ronald 
> and I work against different builds of python [he uses a framework 
> build of 2.3 alpha and I use the Apple supplied-- slightly 
> incomplete-- build of 2.2] and work with a different set of examples 
> largely to provide testing.
I try to test new features using 'Apple Python', but my primary Python 
environment is Python 2.3alpha. Having a unit testing suite would 
indeed be very usefull. I'd like to use PyUnit (which IIRC is what is 
used by the Python testsuite).

> Documentation:
Documentation is a very much needed. There is some documentation, but 
it needs to be fleshed out. Luckily we don't need a lot of it :-)
>
> ---
>
> Examples:
>
>     - need a general clean up and synchronization with underlying 
> features (example:  web services tool currently does a bunch 
> additional selector() definitions that are likely completely 
> unnecessary)
>
>     - remove examples that no longer work correctly or are rendered 
> moot by unit testing
<nod> Most of the current examples are actually scripts that I used to 
test the code.

> ---
>
>     Remove all references to True and False throughout codebase 
> [assuming we are to continue supporting 2.2 throughout] -- or declare 
> 'em somewhere.
I'd prefer to declare True and False on Python 2.2.0. Although the 
values don't really add functionality they do help with readability.

Ronald