Re: [Pyobjc-dev] toplevel modules

[<bb...@ma...>]

On Sunday, Feb 16, 2003, at 14:41 US/Eastern, Ronald Oussoren wrote:
> I'm getting worried about the toplevel modules/packages introduced by 
> PyObjC, especially after introducing 3 new ones while playing around 
> with the PreferencePanes framework (none of these are in CVS at the 
> moment).
>
> We currently introduce 4 toplevel packages, the bridge itself and 
> wrappers for Foundation, AppKit and AddressBook. If the hacking I'm 
> doing on Python based plugins ends up with something usefull there 
> will also be PreferencePanes, ScreenSaver and InterfaceBuilder 
> packages.
>
> The reason I'm starting to get worried is that both AddressBook and 
> InterfaceBuilder are not only Cocoa frameworks but also 
> AppleScriptable applications. From my limited research I deduct that 
> the Python interface to the AppleScript functionality in AddressBook 
> would also be in a module named AddressBook if MacPython would have 
> such a convenience module (which is doesn't) [e.g. try 'import 
> CodeWarrior', you get a module that allows access to CodeWarrior 
> through its AppleScript interface].
>
> Another reason for worries is that AddressBook also has a C API 
> (although just using PyObjC would probably be easier). Other 
> frameworks might also have both a C and Objective-C API, which might 
> lead to conflicts if both versions are wrapped (DiskRecording seems to 
> have both C and Objective-C APIs).

Agreed.   Two thoughts.

First:   We should split out the optional frameworks that build on top 
of PyObjC but are not a part of the core.   Preferences, Address Book, 
NetInfo [a personal plaything I have been hacking on], and others into 
a new top level project in the PyObjC repository.  "Modules" or 
"ThirdParty" or "Optional" or something.

Each additional framework should have its own root, its own setup.py, 
etc...

Second:  maybe we should reconsider importing things through the pyobjc 
root?   I.e. 'from pyobjc import AddressBook'.  The goal would be to 
use 'pyobjc' as a root namespace through which all pyobjc related 
modules are imported whether they are a part of the core or an optional 
add on.

I know that the primary opposition is that 'from pyobjc.AppKit import 
*' is ugly and that the goal of pyobjc is to effectively make it as 
transparent as possible, but I think there is real value in 
perpetuating a consistent hierarchical namespace across the solution.  
In particular, that the AppKit is being glued into Python via PyObjC 
is, and always will be, a significant bit of knowledge.   'from pyobjc 
import AppKit' or 'from pyobjc.AppKit import *' gives the developer a 
keyword through which to figure out what the heck is going on.

I always like to apply the Google test:

If I search for 'AppKit' or 'AppKit python', PyObjC doesn't appear or 
is fairly far down the list.  If I search for 'pyobjc appkit', it is 
obviously one of the first hits...

Imagine that you are a developer who downloaded a random app and 
cracked it open to discover MyAppDelegate.py.   You open up that odd 
little source file and see that one of the first statements is an 
import of the AppKit -- 'from pyobjc.AppKit import *' provides you with 
a lot more of a chance of finding out what is really going on than just 
a 'from AppKit import *'....

b.bum