[Pythonmac-SIG] State of Python on the Mac

[Jack Jansen]

On zaterdag, maa 1, 2003, at 08:01 Europe/Amsterdam, Nick Matsakis 
wrote:

>
> On Sat, 1 Mar 2003, Jack Jansen wrote:
>
>> If people want to read the "in development" part of the documentation:
>> please do so and let me know the problems.
>
> Where is this?  In CVS?  Perhaps it could be put on the web somewhere 
> to
> lower the barrier to people perusing it.  Just write *DRAFT* all over
> it...

It's on www.python.org. Go to the "documentation" page, then follow the 
link that says something like "browse in-development version of the 
docs".

>>> 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).
>
>> Is this the way it should be structured, or would a problem-oriented
>> approach be better?
>
> The reason I suggested they be grouped by framework is that these
> frameworks have relatively independent pedigrees.  I expect that 
> programs
> will generally fall primarily into a single category, while still 
> taking
> functionality from the others where needed.
>
> For example, if a program requires access to a network resource, which
> abstraction should they use?  The Cocoa one? The Carbon one? The
> Python/Unix one?  I think it really depends on what the primary 
> technology
> the rest of the program is using. If it is a highly-interactive GUI 
> app,
> the programmer may chose pyobjc and Cocoa.  In this case, it would make
> sense to utilize the Cocoa networking API, since this will likely
> interface well with the GUI components.  On the other hand, if the app 
> is
> going to download web pages and extract information to process as a 
> batch
> job, the standard Python APIs would probably be sufficient.
>
> So, perhaps it would be best to combine the "framework-centered"
> approach with the "problem-centered" approach by first describing the
> frameworks, and the describing what problems are amenable to what
> frameworks.

Sounds reasonable...

> Perhaps as an example I should offer a script I wrote to do system 
> backups
> in conjunction with Retrospect. [...]

The description sounds interesting, but there's one problem with this 
as an
example: not everyone has retrospect. This is a problem the MacOS9 
MacPython
scripting examples have also had for a long time.

I think I do have an interesting example that can be used to 
demonstrate sysadmin-like
tasks: a script that looks for text files (either .txt extension or 
TEXT type)
that have non-native end of line convention. This would be easy to 
understand as a script,
and moreover could be extended with a GUI to demonstrate Cocoa, 
wxPython and Tkinter.

But for scripting I don't have any ideas yet. Something with Mail or 
Address book
or iTunes or so springs to mind, but I'm not really sure what. Best 
would be something that
is difficult or impossible to do in the host program.
--
- 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 -