[Pythonmac-SIG] Reorganize the Carbon package?

[Jack Jansen]

Folks,
The Carbon package is a bit of a mess right now. Or, let me 
rephrase that, there is stuff in there that isn't part of the 
Carbon framework in Apple's documentation: QuickTime and 
CoreFoundation. Moreover, everything inside it is grouped by the 
old MacOS9 toolbox names (Win, Res, Dlg, etc).

This is something that will have to change at some point, but 
the question is, should we try to fix this before Python 2.3 is 
released, or should we wait until 2.4? Of course, any fix will 
have a 1-release backwards compatibility, as was done for the 
Res->Carbon.Res change in Python 2.2.

I can see a couple of options, all with specific advantages and 
drawbacks, and I'd like some feedback.

1. Do nothing for 2.3, leave it for 2.4. Advantage is that I 
have enough work already. Disadvantage is that I expect 2.3 to 
be a turning-point release where we can significantly enlarge 
our audience.

2. Move QuickTime to its own package (QuickTime.Qt and 
QuickTime.QuickTime for the constants), move CF to its own 
package (CoreFoundation.CF and CoreFoundation.CoreFoundation) 
and leave it at that. Advantage is that it's fairly easy to do, 
disadvantage is that it's only a half-way solution.

3. In addition to (2) we could get rid of the funny distinction 
between constants and objects/methods that is an artefact of the 
way the modules are created. I.e. the user would always import 
Carbon.Windows and that module would contain both the constants 
and the methods and objects. Advantage is that QuickTime and 
CoreFoundation are then 100% compatible to the documentation, 
disadvantage is that Carbon isn't. Moreover, the namespaces of 
the various modules will become pretty big.

4. In addition to (3) we actually create a module Carbon.Carbon 
that imports everything from every Carbon module in the system. 
Advantage is that by using this module everything is 100% 
compatible with the Apple documentation. Disadvantage is that 
the namespace for this module is mindbogglingly large. And, if 
you really need only one single Carbon call you will still drag 
in all the extension modules, etc.

5. In stead of (4) we might be able to come up with some lazy 
dynamic scheme. I.e. the module (or module-like object) 
Carbon.Carbon doesn't import anything initially, but when you 
try to access, say, Carbon.Carbon.NewWindow it will somehow find 
out that this should come from Carbon.Win and at that point do 
the actual import (and populating its own namespace with all its 
symbols). Advantage is the same as for (4). Disadvantage is that 
I don't know how to do this:-), "from Carbon.Carbon import *" 
may be a problem, for instance, and that introspection (think of 
the IDE class browser) will work in a funny way.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -