[Pythonmac-SIG] Reorganize the Carbon package?

[Just van Rossum]

Jack Jansen wrote:

> 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.

My vote would be for #2 or #1, in order of preference.

> 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.

Big, but not as big as a merged Carbon module would become.

> 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.

-1. Waaay too much stuff. This is Python, not C after all. We _have_ multiple
namespaces...

> 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.

-1. Agree completely with Michael Hudson. This kind of magic is evil.

Just
(who is on vacation, so will only sporadically be able to check his email, let
alone answer it)