Re: [Pyobjc-dev] Separating functionality into modules

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

On Tuesday, Nov 19, 2002, at 13:48 Europe/Amsterdam, Jack Jansen wrote:

>
> On Monday, Nov 18, 2002, at 16:45 Europe/Amsterdam, bb...@ma... wrote:
>>> 4. Why AddressBook is included completely eludes me. Is this 
>>> framework somehow
>>>    more important than the other ones, or is this really only an 
>>> example?
>>
>> At the moment, it is the only first-class, high level, OO API 
>> included with the system that is not highly application specific 
>> [PreferencesPane, ScreenSaver, Project Builder] and includes a public 
>> API.   It is generically useful and represents functionality that 
>> quite a number of developers will want to use.
>
> Ok, fair enough.

I added it because (a) it was easy to do and (b) because it is an Apple 
provided Objective-C framework/class library.

BTW. AddressBook.framework can also be used with plain C code. That may 
cause problems later on if you decide to also wrap this framework :-)

>>
>>> If for (4) I'm correct and AddressBook is just an example, shouldn't 
>>> we provide a general solution in the form of a factory function so 
>>> the user can do
>>> AddressBook = 
>>> Foundation.Python.GenerateModuleForBundle("AddressBook")
>>
>> It requires a compiled component to wrap a framework such that 
>> enumerated types, #defines, and functions can be exported.  Ronald 
>> has done an amazing job of automating the generating of the wrappers, 
>> but it needs some work before it could automatically generate a 
>> module project to wrap a specific framework.  That would be very, 
>> very > cool...
>
> Oops, I missed that bit, I didn't realise there was an extension 
> module too, I thought it was pure python.
> [search.... search....]
> No, I can't find it. Are you sure that this module isn't pure Python? 
> Because if it is then my factory function idea should work (create a 
> module, populate it with the classes returned by 
> Foundation.load_bundle, return the module).
> And, if there is C code for AddressBook: where is it?

This module is pure Python code. I think Bill is refering to the 
general case.

That said, I'd like to build a module or script to build a template 
from wrapping yet another Objective-C class library. I don't think it 
would be usefull to use 'AddressBook = 
Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
replacement for 'import AddressBook'

>
>>> We need a new place to put Python-specific modules, at the moment 
>>> only for
>>> AppKit but later we may want this for the other packages too. I can 
>>> see two simple solutions:
>>> A. Put them in a sub-package. Foundation.Python comes to mind, but 
>>> there may
>>>    be better names.
>>> B. Prefix them with "Py". Again, another prefix is also possible.
>>
>> Before we go here, how much functionality are we actually talking 
>> about?
>
> At the moment there isn't much, indeed, but I can imagine it growing.
[nifty examples removed]

I agree with Jack. We should split of all user-visible extentions to 
seperate modules. There are few of these now but the number will grow.

As for a naming convention... Currently my favorite is a Python 
subpackage (Foundation.Python.Foo, AppKit.Python.Foo, ...).

>>> Oh yes: I want a version number somewhere, probably in objc. I don't 
>>> really care whether there's a static version number or a function 
>>> that returns a version number, but I need a version number for my 
>>> Python Installation Manager (which will help keep the size of 
>>> MacPython distributions down, but still allow pretty easy access to 
>>> any package for end users; see the pythonmac-sig discussions for 
>>> more details).

It is already there:
 >>> import objc
 >>> print objc.__version__
0.7.1
 >>>

Ronald