[Pythonmac-SIG] State of Python on the Mac

[Jack Jansen]

Nick (and everyone),
documentation is what is topmost on my priority list from now until the
release of 2.3 final. Or actually I should broaden that a bit: 
documentation
plus a couple of well-chosen examples plus packaging and ease of
installation and use. I could definitely use help with this!

I'll comment on some of the points you make:

> I appreciate that a lot of work is going on to build a stable platform 
> for
> the future, but the documentation is hopelessly out of date.  Though 
> the
> footer says "updated October 14, 2002", the documents at
> http://www.python.org/doc/current/mac/mac.html say "At the time of this
> writing Mac OS X had just been released as a Public Beta." Which makes 
> me
> wonder if I can trust the rest of it at all.

If people want to read the "in development" part of the documentation:
please do so and let me know the problems. A lot of the stuff is still
centered around MacOS9, but at least it should now clearly be flagged
as such.

> Instead, what I really want is a 1-2 page "state of Python on the Mac"
> written for a forward-looking programmer who is interested in using 
> Python
> to script Mac OS X or write Carbon or Cocoa applications. The things it
> should provide are:

Good idea! Let's muse on this some more:
>
> 1. A bird's eye view of the APIs.  The module list at
> http://www.python.org/doc/current/ is alphabetized, and thus random.  I
> can make some reasonable intferences, but I really have no idea what
> modules "go together".  If all goes well, a future Mac-python 
> programmer
> will like have sets of modules that correspond roughly to "Cocoa"
> (pyobjc), "Carbon" (MacPython), "Applescript/OSA" (MacPython), and
> "standard python OS abstractions" (os, sys).  Which modules belong 
> where,
> which work well together, and which, if any, are deprecated?

Is this the way it should be structured, or would a problem-oriented 
approach
be better? I.e. "learning programming", "web services", "system tools",
"scientific programming", etc. Some areas that aren't really 
domain-related
probably deserve a section too (GUI programming springs to mind).

> 2. A small description of the available and future python runtimes, and
> what to expect in the future.  Apple included Python with 10.2.  Why?
> Because it was in BSD 4.4? Because people asked for it?  Has Apple 
> made an
> official statement about its position on Python, or what versions of
> Python will be included with future versions of Mac OS X?  
> (frameworks?)
> These are all important questions for the programmer who is trying to
> decide whether Python is appropriate for a given project.

Good question, and one I haven't found the answer to. I know that some 
people
here might have some insight in this, if they don't feel like answering 
in
public please let me know in private (if it's okay to forward this info 
anonymized).

I did bug Jordan Hubbard about MacPython at a dinner about a year and a 
half
ago, maybe that influenced it:-)

> 3. A small description of the state of using Python as an OSA script.
> This is actually where _my_ primary interest lies. My impression of 
> OSA is
> that it is supposed to allow different languages to be used to send and
> handle Apple Events.  I hope that one day I would be able to install a
> simple component into the system and that suddenly I would be able to 
> use
> Python as a full peer to Applescript; that is, anywhere that 
> Applescript
> is used by applications and the system I could plug in Python.  (My 
> other
> impression is that the support may not yet be there from Apple, but 
> that
> they are working on it, is this true?).

Bill Fancher was working on this, but at the moment he is unable to 
pursue
it. I'll try and contact him again.
>
> 4. A solid answer to the question, "How can I help?" It's clear that
> documentation and other work is needed. Is the time appropriate to do
> that?  How can documentation efforts be coordinated?

Primarily reading, and pointing out problems. If people want to go 
further:
context diffs with the documentation LaTex sources are of course always 
much
better than plain old comments, but even the plain old comments are very
valuable!

[Actually: with fink it is reasonably easy to setup the tools you
need to build the documentation from source. It used to be pure hell,
but nowadays I think that if you install the latex stuff first there's 
only
one bit missing, and its pretty clear what that is (and its also under 
fink)]
--
- 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 -