From hengist.podd at virgin.net  Sat Dec  1 22:40:42 2007
From: hengist.podd at virgin.net (has)
Date: Sat, 1 Dec 2007 21:40:42 +0000
Subject: [Pythonmac-SIG] appscript create new iphoto album
In-Reply-To: <mailman.6.1196334003.25132.pythonmac-sig@python.org>
References: <mailman.6.1196334003.25132.pythonmac-sig@python.org>
Message-ID: <6459E023-F96E-4CEE-BB2F-56222B20E077@virgin.net>

David Voswinkel wrote:

> But now iam stuck with the task to add a photo  to a referenced album.

AFAIK the only way to bring in image files is via the 'open' command,  
e.g.:

	iphoto.open([Alias('/path/to/image1.jpg'), Alias('/path/to/ 
image2.jpg')])

To add existing 'photo' objects to a specific album, use the 'add'  
comment, e.g.:

	iphoto.add(app.albums['Last Import'].photos, to=app.albums['My Album'])

HTH

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org


From chris.van.bael at gmail.com  Sun Dec  2 15:18:14 2007
From: chris.van.bael at gmail.com (Chris Van Bael)
Date: Sun, 2 Dec 2007 15:18:14 +0100
Subject: [Pythonmac-SIG] Get the locale on OSX
Message-ID: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>

Hi,

I'm trying to port an python application which runs fine on Windows
and Linux to OSX.
However, it seems "lang = locale.getdefaultlocale()[0]" doesn't work.
I've searched quite some bit on the Internet and on this mailinglist,
and apparently it is a problem, but I haven't found any solution for
it.
Does anybody here have one?

Thanks,

Chris

From formido at gmail.com  Mon Dec  3 08:07:46 2007
From: formido at gmail.com (Michael Terry)
Date: Sun, 2 Dec 2007 23:07:46 -0800
Subject: [Pythonmac-SIG] Embedding Python in Cocoa
Message-ID: <3e9445610712022307y1380a233q3e8500d3ec729937@mail.gmail.com>

Hi,

Suppose you had a Cocoa program that executed Python scripts
periodically. If global variables were set, they'd retain their values
between script runs. What would be the best approach to make this
happen?

Call the C APIs? If so, do I just need to initialize a Python
interpreter when the program starts and not finalize it until the
program closes--or will it be more complicated than that?

Control interactive Python with Expect?

Something else?

Thanks,
Michael Terry

From njriley at uiuc.edu  Mon Dec  3 08:40:56 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Mon, 3 Dec 2007 01:40:56 -0600
Subject: [Pythonmac-SIG] Get the locale on OSX
In-Reply-To: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>
References: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>
Message-ID: <20071203074056.GA8776@uiuc.edu>

On Sun, Dec 02, 2007 at 03:18:14PM +0100, Chris Van Bael wrote:
> I'm trying to port an python application which runs fine on Windows
> and Linux to OSX.
> However, it seems "lang = locale.getdefaultlocale()[0]" doesn't work.
> I've searched quite some bit on the Internet and on this mailinglist,
> and apparently it is a problem, but I haven't found any solution for
> it.

What are you trying to do with the locale information?  Leopard's
Terminal does have an option to 'set LANG environment variable on
startup', which when checked does cause locale.getdefaultlocale() to
work, but this is of no help in general.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

From chris.van.bael at gmail.com  Mon Dec  3 09:26:40 2007
From: chris.van.bael at gmail.com (Chris Van Bael)
Date: Mon, 3 Dec 2007 09:26:40 +0100
Subject: [Pythonmac-SIG] Get the locale on OSX
In-Reply-To: <20071203074056.GA8776@uiuc.edu>
References: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>
	<20071203074056.GA8776@uiuc.edu>
Message-ID: <5465ee790712030026j3a386912p36b84dac02caf435@mail.gmail.com>

On Dec 3, 2007 8:40 AM, Nicholas Riley <njriley at uiuc.edu> wrote:
> On Sun, Dec 02, 2007 at 03:18:14PM +0100, Chris Van Bael wrote:
> > I'm trying to port an python application which runs fine on Windows
> > and Linux to OSX.
> > However, it seems "lang = locale.getdefaultlocale()[0]" doesn't work.
> > I've searched quite some bit on the Internet and on this mailinglist,
> > and apparently it is a problem, but I haven't found any solution for
> > it.
>
> What are you trying to do with the locale information?  Leopard's
> Terminal does have an option to 'set LANG environment variable on
> startup', which when checked does cause locale.getdefaultlocale() to
> work, but this is of no help in general.

Well,

it's for some educational games: Childsplay and Schoolsplay
(www.schoolsplay.org)
Based on the locale information, we choose different languages to use
in the strings and also different alphabet sound files.
We do have an commandline option to set the language, so "schoolsplay
--language=nl_BE" would give Dutch strings and sounds.
However the nicest option would be that it searched in the settings of the OS.
The program would be packed btw with py2app, so and end user wouldn't
have to use the Terminal (and install all Python dependencies).

From andrew at trevorrow.com  Tue Dec  4 00:17:45 2007
From: andrew at trevorrow.com (Andrew Trevorrow)
Date: Tue, 4 Dec 2007 10:17:45 +1100
Subject: [Pythonmac-SIG] Embedding Python in Cocoa
In-Reply-To: <3e9445610712022307y1380a233q3e8500d3ec729937@mail.gmail.com>
References: <3e9445610712022307y1380a233q3e8500d3ec729937@mail.gmail.com>
Message-ID: <f05200f01c37a3bf930a7@[192.168.1.3]>

Michael Terry wrote:

> Suppose you had a Cocoa program that executed Python scripts
> periodically. If global variables were set, they'd retain their values
> between script runs. What would be the best approach to make this
> happen?
> 
> Call the C APIs? If so, do I just need to initialize a Python
> interpreter when the program starts and not finalize it until the
> program closes--or will it be more complicated than that?

Yep, just call Py_Initialize once.  In fact, it's not a good idea
to call Py_Initialize and Py_Finalize multiple times because they
cause a memory leak of about 10K each time.  In our app we don't
even bother calling Py_Finalize at the end because it causes a
slight but annoying delay.

If you want to see the way we do things then go to
https://sourceforge.net/projects/golly/
and either browse CVS or download the source code and look at
wxpython.cpp.

Andrew

From formido at gmail.com  Tue Dec  4 08:45:35 2007
From: formido at gmail.com (Michael Terry)
Date: Mon, 3 Dec 2007 23:45:35 -0800
Subject: [Pythonmac-SIG] Embedding Python in Cocoa
In-Reply-To: <f05200f01c37a3bf930a7@192.168.1.3>
References: <3e9445610712022307y1380a233q3e8500d3ec729937@mail.gmail.com>
	<f05200f01c37a3bf930a7@192.168.1.3>
Message-ID: <3e9445610712032345p3450233dq356a424ba72edcf1@mail.gmail.com>

Sweet, thanks!

Michael

On 12/3/07, Andrew Trevorrow <andrew at trevorrow.com> wrote:
> Michael Terry wrote:
>
> > Suppose you had a Cocoa program that executed Python scripts
> > periodically. If global variables were set, they'd retain their values
> > between script runs. What would be the best approach to make this
> > happen?
> >
> > Call the C APIs? If so, do I just need to initialize a Python
> > interpreter when the program starts and not finalize it until the
> > program closes--or will it be more complicated than that?
>
> Yep, just call Py_Initialize once.  In fact, it's not a good idea
> to call Py_Initialize and Py_Finalize multiple times because they
> cause a memory leak of about 10K each time.  In our app we don't
> even bother calling Py_Finalize at the end because it causes a
> slight but annoying delay.
>
> If you want to see the way we do things then go to
> https://sourceforge.net/projects/golly/
> and either browse CVS or download the source code and look at
> wxpython.cpp.
>
> Andrew
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From smgava at smgava.com  Wed Dec  5 13:48:42 2007
From: smgava at smgava.com (Stephen Gava)
Date: Wed, 5 Dec 2007 23:48:42 +1100
Subject: [Pythonmac-SIG] py2app "bus error" on leopard
Message-ID: <78614529-341F-4B2A-873C-C093A0133E62@smgava.com>

Lo all,

I'm trying to bundle an app using py2app on osx leopard. I'm using the  
0.3.6 version of py2app and my app is written and built with the  
framework version of python 2.5.2.

When I run my app as a normal script it runs fine, and the wxpython  
gui displays and works normally, but when I use py2app to creapte a  
bundle it throws a meaningless (to me) error every time I try to  
launch the created app, either by using open on the .app bundle or by  
running the script inside the bundle directly.

The app tries to start up (a python launcher icon appears in the dock)  
but then crashes. If I'm running the script inside the bundle from a  
terminal I get "bus error" output to the console when it crashes. If  
I'm using open to run the bundle, after it crashes I get the standard  
osx crashed app dialog, and the traceback there states:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000038

among other things.

Anyone got any idea what the problem is?

Thanks,
Stephen.


From chris.van.bael at gmail.com  Wed Dec  5 14:12:12 2007
From: chris.van.bael at gmail.com (Chris Van Bael)
Date: Wed, 5 Dec 2007 14:12:12 +0100
Subject: [Pythonmac-SIG] Get the locale on OSX
In-Reply-To: <5465ee790712030026j3a386912p36b84dac02caf435@mail.gmail.com>
References: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>
	<20071203074056.GA8776@uiuc.edu>
	<5465ee790712030026j3a386912p36b84dac02caf435@mail.gmail.com>
Message-ID: <5465ee790712050512v4c4ce5cdob829a214fa54c745@mail.gmail.com>

On Dec 3, 2007 9:26 AM, Chris Van Bael <chris.van.bael at gmail.com> wrote:
> On Dec 3, 2007 8:40 AM, Nicholas Riley <njriley at uiuc.edu> wrote:
> > On Sun, Dec 02, 2007 at 03:18:14PM +0100, Chris Van Bael wrote:
> > > I'm trying to port an python application which runs fine on Windows
> > > and Linux to OSX.
> > > However, it seems "lang = locale.getdefaultlocale()[0]" doesn't work.
> > > I've searched quite some bit on the Internet and on this mailinglist,
> > > and apparently it is a problem, but I haven't found any solution for
> > > it.
> >
> > What are you trying to do with the locale information?  Leopard's
> > Terminal does have an option to 'set LANG environment variable on
> > startup', which when checked does cause locale.getdefaultlocale() to
> > work, but this is of no help in general.
>
> Well,
>
> it's for some educational games: Childsplay and Schoolsplay
> (www.schoolsplay.org)
> Based on the locale information, we choose different languages to use
> in the strings and also different alphabet sound files.
> We do have an commandline option to set the language, so "schoolsplay
> --language=nl_BE" would give Dutch strings and sounds.
> However the nicest option would be that it searched in the settings of the OS.
> The program would be packed btw with py2app, so and end user wouldn't
> have to use the Terminal (and install all Python dependencies).

Anybody any ideas on how to solve my problem?

From ronaldoussoren at mac.com  Wed Dec  5 14:32:50 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 05 Dec 2007 05:32:50 -0800
Subject: [Pythonmac-SIG] Get the locale on OSX
In-Reply-To: <5465ee790712050512v4c4ce5cdob829a214fa54c745@mail.gmail.com>
References: <5465ee790712020618l1163747bpda70a436f64f6111@mail.gmail.com>
	<20071203074056.GA8776@uiuc.edu>
	<5465ee790712030026j3a386912p36b84dac02caf435@mail.gmail.com>
	<5465ee790712050512v4c4ce5cdob829a214fa54c745@mail.gmail.com>
Message-ID: <5C8993A2-0116-1000-A704-FE1AFD45468F-Webmail-10013@mac.com>

 
On Wednesday, December 05, 2007, at 02:15PM, "Chris Van Bael" <chris.van.bael at gmail.com> wrote:
>On Dec 3, 2007 9:26 AM, Chris Van Bael <chris.van.bael at gmail.com> wrote:
>> On Dec 3, 2007 8:40 AM, Nicholas Riley <njriley at uiuc.edu> wrote:
>> > On Sun, Dec 02, 2007 at 03:18:14PM +0100, Chris Van Bael wrote:
>> > > I'm trying to port an python application which runs fine on Windows
>> > > and Linux to OSX.
>> > > However, it seems "lang = locale.getdefaultlocale()[0]" doesn't work.
>> > > I've searched quite some bit on the Internet and on this mailinglist,
>> > > and apparently it is a problem, but I haven't found any solution for
>> > > it.
>> >
>> > What are you trying to do with the locale information?  Leopard's
>> > Terminal does have an option to 'set LANG environment variable on
>> > startup', which when checked does cause locale.getdefaultlocale() to
>> > work, but this is of no help in general.
>>
>> Well,
>>
>> it's for some educational games: Childsplay and Schoolsplay
>> (www.schoolsplay.org)
>> Based on the locale information, we choose different languages to use
>> in the strings and also different alphabet sound files.
>> We do have an commandline option to set the language, so "schoolsplay
>> --language=nl_BE" would give Dutch strings and sounds.
>> However the nicest option would be that it searched in the settings of the OS.
>> The program would be packed btw with py2app, so and end user wouldn't
>> have to use the Terminal (and install all Python dependencies).
>
>Anybody any ideas on how to solve my problem?

You could use PyObjC to find the right locale, and wxWidgets also seems to have functions for getting the locale (wxLocale class). 

BTW. It would have helped if you would have stated up front that schoolsplay is using wxWidgets as the GUI layer, that way there is a larger chance that the right people respond.

Ronald
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From ronaldoussoren at mac.com  Wed Dec  5 14:34:23 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 05 Dec 2007 05:34:23 -0800
Subject: [Pythonmac-SIG] py2app "bus error" on leopard
In-Reply-To: <78614529-341F-4B2A-873C-C093A0133E62@smgava.com>
References: <78614529-341F-4B2A-873C-C093A0133E62@smgava.com>
Message-ID: <5C8993A2-0116-1000-A707-FE1AFD45468F-Webmail-10013@mac.com>

 
On Wednesday, December 05, 2007, at 01:54PM, "Stephen Gava" <smgava at smgava.com> wrote:
>Lo all,
>
>I'm trying to bundle an app using py2app on osx leopard. I'm using the  
>0.3.6 version of py2app and my app is written and built with the  
>framework version of python 2.5.2.
>
>When I run my app as a normal script it runs fine, and the wxpython  
>gui displays and works normally, but when I use py2app to creapte a  
>bundle it throws a meaningless (to me) error every time I try to  
>launch the created app, either by using open on the .app bundle or by  
>running the script inside the bundle directly.
>
>The app tries to start up (a python launcher icon appears in the dock)  
>but then crashes. If I'm running the script inside the bundle from a  
>terminal I get "bus error" output to the console when it crashes. If  
>I'm using open to run the bundle, after it crashes I get the standard  
>osx crashed app dialog, and the traceback there states:
>
>Exception Type:  EXC_BAD_ACCESS (SIGBUS)
>Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000038
>
>among other things.
>
>Anyone got any idea what the problem is?

No. Can you reproduce this using a smaller program? If you, could you post that program.

Ronald


From Bernard.B.Yoo at aero.org  Wed Dec  5 20:17:09 2007
From: Bernard.B.Yoo at aero.org (Bernard B Yoo)
Date: Wed, 5 Dec 2007 11:17:09 -0800
Subject: [Pythonmac-SIG] SWIG on MacOS X 10.4
Message-ID: <OF0C403CEF.F46AC40B-ON882573A8.00696954-882573A8.0069F0E6@notes.aero.org>

Hi,

I'm just joining the list, specifically to figure out how to use SWIG on 
MacOS X 10.4 (intel).  I have the default Apple Python 2.3.5 as well as 
MacPython 2.5 installed.

I've following the tutorial at the swig.org Web site, using the Apple 
Python 2.3.5.  When I try to create the wrapper library, I get a bunch of 
undefined symbols, such as:

_PyArg_ParseTuple
_PyArg_UnpackTuple

These are in the wrapper code produced by SWIG.  How do I include these 
functions in the build of the wrapper library?

I apologize if this has been discussed before.  I didn't see an easy way 
to search the mailing list archive.  Thanks!

Bernard B. Yoo
Engineering Specialist
Astrodynamics Department
(310) 336-8574
(626) 395-0405 (Pasadena)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071205/102d6842/attachment.htm 

From Chris.Barker at noaa.gov  Thu Dec  6 00:02:22 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 05 Dec 2007 15:02:22 -0800
Subject: [Pythonmac-SIG] SWIG on MacOS X 10.4
In-Reply-To: <OF0C403CEF.F46AC40B-ON882573A8.00696954-882573A8.0069F0E6@notes.aero.org>
References: <OF0C403CEF.F46AC40B-ON882573A8.00696954-882573A8.0069F0E6@notes.aero.org>
Message-ID: <47572DFE.9000007@noaa.gov>

Bernard B Yoo wrote:
> I'm just joining the list, specifically to figure out how to use SWIG on 
> MacOS X 10.4 (intel).  I have the default Apple Python 2.3.5 as well as 
> MacPython 2.5 installed.
> 
> I've following the tutorial at the swig.org Web site, using the Apple 
> Python 2.3.5.  When I try to create the wrapper library, I get a bunch 
> of undefined symbols, such as:

First, I highly recommend that you use the the MacPython2.5 python

Second, how are you trying to build your wrappers? If you aren't using 
distutils (setup.py), then you're doing it the hard way. You really want 
to use distutils.

Unfortunately, the SWIG docs didn't tel you how to do this until 
recently. There are directions in the docs in the SWIG svn here:

http://swig.svn.sourceforge.net/viewvc/swig/trunk/Doc/Manual/Python.html?view=log

Hopefully that will make it into the released docs soon.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From vivacarlie at gmail.com  Thu Dec  6 05:36:41 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Wed, 5 Dec 2007 22:36:41 -0600
Subject: [Pythonmac-SIG] vobject
Message-ID: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>

I've been reading here about a few people who've been interfacing with
their
iCal calendars via vobject. To take it directly from the website "VObject
simplifies the process of parsing and creating iCalendar and vCard objects"
  --(http://vobject.skyhouseconsulting.com/usage.html)
perhaps you could point your python to the ical callendar store place (i
forget where this is but its documented at apple somewhere ) and edit the
ical calendar objects with this. Now you can use a well documented,
programmatic interface to your ical calendars instead of using appscript.
-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071205/7031fb3d/attachment.htm 

From dwf at cs.toronto.edu  Thu Dec  6 08:26:43 2007
From: dwf at cs.toronto.edu (David Warde-Farley)
Date: Thu, 6 Dec 2007 02:26:43 -0500
Subject: [Pythonmac-SIG] vobject
In-Reply-To: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
References: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
Message-ID: <CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>

On 5-Dec-07, at 11:36 PM, Nehemiah Dacres wrote:

> perhaps you could point your python to the ical callendar store  
> place (i forget where this is but its documented at apple  
> somewhere ) and edit the ical calendar objects with this. Now you  
> can use a well documented, programmatic interface to your ical  
> calendars instead of using appscript.

I've read about this before and it's a nice idea, however if I were  
writing something for OS X I'd still want to use the application hooks  
for iCal, just to be sure I was getting up to date data. AFAIK Apple  
makes no guarantees about how often the calendar is flushed to disk.

What would be neat is a bridge that reads the iCalendar using  
appscript or something like it, and spits out VObjects (or the same  
deal for Address Book cards), and could flush back from VObject to  
Apple Address Book. I might consider writing the address book portion  
when I get around to coding up an iSync conduit for my obsolete cell  
phone.

David

From ronaldoussoren at mac.com  Thu Dec  6 10:41:48 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 06 Dec 2007 01:41:48 -0800
Subject: [Pythonmac-SIG] vobject
In-Reply-To: <CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>
References: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
	<CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>
Message-ID: <5C8993A2-0116-1000-BF1F-FE1AFD45468F-Webmail-10013@mac.com>

 
On Thursday, December 06, 2007, at 08:34AM, "David Warde-Farley" <dwf at cs.toronto.edu> wrote:
>On 5-Dec-07, at 11:36 PM, Nehemiah Dacres wrote:
>
>> perhaps you could point your python to the ical callendar store  
>> place (i forget where this is but its documented at apple  
>> somewhere ) and edit the ical calendar objects with this. Now you  
>> can use a well documented, programmatic interface to your ical  
>> calendars instead of using appscript.
>
>I've read about this before and it's a nice idea, however if I were  
>writing something for OS X I'd still want to use the application hooks  
>for iCal, just to be sure I was getting up to date data. AFAIK Apple  
>makes no guarantees about how often the calendar is flushed to disk.
>
>What would be neat is a bridge that reads the iCalendar using  
>appscript or something like it, and spits out VObjects (or the same  
>deal for Address Book cards), and could flush back from VObject to  
>Apple Address Book. I might consider writing the address book portion  
>when I get around to coding up an iSync conduit for my obsolete cell  
>phone.

FWIW: Leopard includes API's for accessing iCal's database (the CalendarStore framework) and that framework is wrapped by PyObjC. 

Ronald

>
>David
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From ys at taywa.ch  Fri Dec  7 02:12:58 2007
From: ys at taywa.ch (Yves Serrano)
Date: Fri, 7 Dec 2007 02:12:58 +0100
Subject: [Pythonmac-SIG] python23 under leopard (intel mac)
In-Reply-To: <8C68A83B-B007-442A-AED8-CC9381443639@yas.ch>
References: <8C68A83B-B007-442A-AED8-CC9381443639@yas.ch>
Message-ID: <8E43322B-C17E-4702-A98E-1E93FA7E0F87@taywa.ch>

Hi

I can't get python2.3.6 to work in leopard on an intel mac.

I tried it first with macports afterwards I tried to compile it  
manually.
When I use "./configure --disable-tk --disable-toolbox-glue --disable-  
framework"
and add the line "#define HAVE_BROKEN_POSIX_SEMAPHORES 1" to  
pyconfig.h, I could start python23 without errors, but I doesn't work  
for everything.

Here is the same error I get, when I try to use zope2.8.

Python 2.3.6 (#12, Dec 6 2007, 23:19:03) [GCC 4.0.1 (Apple Inc. build  
5465)] on darwin Type "help", "copyright", "credits" or "license" for  
more information.
 >>> import asyncore
Traceback (most recent call last): File "<stdin>", line 1, in
File "/tmp/py23/lib/python2.3/asyncore.py", line 56,
in from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \
ImportError: cannot import name ESHUTDOWN

I also tried the options under http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2005_05_21_compiling_python_2_3_5 
     (tips for tiger)

Any Ideas? Could it be, that this has todo something with posix  
changes in leopard?
For some projects, I can't switch to python24 or python25 at the  
moment and need to use python23.

regards Yves

From ronaldoussoren at mac.com  Fri Dec  7 09:38:53 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 7 Dec 2007 09:38:53 +0100
Subject: [Pythonmac-SIG] python23 under leopard (intel mac)
In-Reply-To: <8E43322B-C17E-4702-A98E-1E93FA7E0F87@taywa.ch>
References: <8C68A83B-B007-442A-AED8-CC9381443639@yas.ch>
	<8E43322B-C17E-4702-A98E-1E93FA7E0F87@taywa.ch>
Message-ID: <EDCEB401-49D8-48DA-A97A-7435302DFC27@mac.com>


On 7 Dec, 2007, at 2:12, Yves Serrano wrote:

> Hi
>
> I can't get python2.3.6 to work in leopard on an intel mac.

Try running configure with MACOSX_DEPLOYMENT_TARGET set to 10.5 in the  
environment.  Python 2.5.1 also misconfigures (fixed in the repository  
and hance 2.5.2 whenever that is released) when the deployment target  
isn't explicitly set.

Ronald


From ys at taywa.ch  Fri Dec  7 12:46:26 2007
From: ys at taywa.ch (Yves Serrano)
Date: Fri, 7 Dec 2007 12:46:26 +0100
Subject: [Pythonmac-SIG] python23 under leopard (intel mac)
In-Reply-To: <EDCEB401-49D8-48DA-A97A-7435302DFC27@mac.com>
References: <8C68A83B-B007-442A-AED8-CC9381443639@yas.ch>
	<8E43322B-C17E-4702-A98E-1E93FA7E0F87@taywa.ch>
	<EDCEB401-49D8-48DA-A97A-7435302DFC27@mac.com>
Message-ID: <CCB5524F-757B-4C28-8CDF-C3A3CC8FAAD3@taywa.ch>

>
> On 7 Dec, 2007, at 2:12, Yves Serrano wrote:
>
>> Hi
>>
>> I can't get python2.3.6 to work in leopard on an intel mac.
>
> Try running configure with MACOSX_DEPLOYMENT_TARGET set to 10.5 in  
> the environment.  Python 2.5.1 also misconfigures (fixed in the  
> repository and hance 2.5.2 whenever that is released) when the  
> deployment target isn't explicitly set.
>
> Ronald
>

Thanks a lot!
I used "export MACOSX_DEPLOYMENT_TARGET=10.5" and edited pyconfig.h  
after configure.

I changed this values:
#undef _POSIX_C_SOURCE
#undef _XOPEN_SOURCE
#define HAVE_BROKEN_POSIX_SEMAPHORES
after that it worked
regards Yves

From JKelly at nemetschek.net  Fri Dec  7 17:26:45 2007
From: JKelly at nemetschek.net (James Kelly)
Date: Fri, 07 Dec 2007 11:26:45 -0500
Subject: [Pythonmac-SIG] Opening files with Japanese characters on Tiger
Message-ID: <C37EDE75.537B%JKelly@nemetschek.net>

Hi all,

I ran into an issue recently opening files with Japanese characters on
Tiger.  Essentially I am reading from a utf-8 file containing lists of file
names.  Most are completely in English, a few contain Japanese characters in
the filename.  I am opening the files for a binary write.  Unfortunately
when I do this, and the filename contains Japanese characters, I get an
exception of type exceptions.IOError, with the specific exception being an
'invalid mode: wb.'

I've tried changing the encoding of the string in various ways, but as far
as I know, I should be passing in a utf-8 string to open, and the string is
already in utf-8.

This does work on Leopard, however.  I don't actually think it's a Python
issue directly though, as we're using py2app, so the python being used is
the same in (Python 2.5.0 from pythonmac.org) testing this on both Tiger and
Leopard.  There seems to be some underlying interaction with the file system
that is not going well on Tiger.  Any ideas?  Googling has really only
turned up this:

http://www.selenic.com/mercurial/bts/issue481

Which seems to be a similar issue.  Perhaps my google-foo is weak.  :)

At any rate, a work around has been instituted, the open command is in a
try/except block, and if the exception is thrown, we just write the file to
a temporary English file, then do a rename to the Japanese filename.  It
works, but it would be nice to not have to do that.

Any ideas appreciated, and I may end up at Filesystem-Dev, I just figured I
would start here.  Thanks!

Jim


From hraban at fiee.net  Sat Dec  8 00:39:54 2007
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Sat, 8 Dec 2007 00:39:54 +0100
Subject: [Pythonmac-SIG] Opening files with Japanese characters on Tiger
In-Reply-To: <C37EDE75.537B%JKelly@nemetschek.net>
References: <C37EDE75.537B%JKelly@nemetschek.net>
Message-ID: <4B8E8F83-8E80-411F-A5D7-118A8A018940@fiee.net>

Am 2007-12-07 um 17:26 schrieb James Kelly:

> I ran into an issue recently opening files with Japanese characters on
> Tiger.  Essentially I am reading from a utf-8 file containing lists  
> of file
> names.  Most are completely in English, a few contain Japanese  
> characters in
> the filename.  I am opening the files for a binary write.   
> Unfortunately
> when I do this, and the filename contains Japanese characters, I  
> get an
> exception of type exceptions.IOError, with the specific exception  
> being an
> 'invalid mode: wb.'

Don't know if this could be the reason, but did you take OSX's  
decomposed Unicode in the filesystem into account?
I often struggle with that stuff.
Maybe there's a difference between 10.4 and 10.5, I don't know.

Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net
https://www.cacert.org (I'm an assurer)



From ceball at users.sf.net  Sat Dec  8 01:40:11 2007
From: ceball at users.sf.net (C. E. Ball)
Date: Sat, 8 Dec 2007 08:40:11 +0800
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
Message-ID: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>

Hi,

On OS X, I'd like to be able to build my own copy of Python that uses
my own copy of Tkinter (built for X11). I've seen several posts to
this list where people mention building python this way (e.g. [1] and
[2] below), but I'm pretty unfamiliar with the concepts, so I wonder
if someone could give me some more help, or point me to a place where
there are some instructions?

I found the only way I could get Python to build using my own tcl and
tk was by renaming OS X's Tk and Tcl framework directories so that
they would not be found. Is there some alteration I can make to
python's setup.py instead?

I'd like to have Python use X11 rather than Aqua so that I can run
automated (buildbot) tests of an application (that is based on Python)
on a virtual (Xvfb) display.

Thanks very much,
Chris

[1] http://article.gmane.org/gmane.comp.python.apple/12394/
[2] http://article.gmane.org/gmane.comp.python.apple/12897/

From ceball at users.sf.net  Sun Dec  9 07:31:25 2007
From: ceball at users.sf.net (C. E. Ball)
Date: Sun, 9 Dec 2007 14:31:25 +0800
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
In-Reply-To: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
References: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
Message-ID: <4e2a3a120712082231j178f4da4nb19fee5d5cb4fd56@mail.gmail.com>

On Dec 8, 2007 8:40 AM, C. E. Ball <ceball at users.sf.net> wrote:
[...]
> I found the only way I could get Python to build using my own tcl and
> tk was by renaming OS X's Tk and Tcl framework directories so that
> they would not be found. Is there some alteration I can make to
> python's setup.py instead?

When building Python on linux, I pass
"LDFLAGS=-Wl,-rpath,/path/to/lib" to configure so that Python finds my
specific lib files (including the tcl and tk ones). On OS X I tried
"LDFLAGS=-rpath,/path/to/lib" but it doesn't seem to make any
difference (and I don't know what I'm doing).

From ed_hartley at mac.com  Mon Dec 10 02:02:33 2007
From: ed_hartley at mac.com (Edward Hartley)
Date: Mon, 10 Dec 2007 01:02:33 +0000
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
Message-ID: <2630DEE4-DB56-45D8-B22A-BBF122383A4B@mac.com>

From: "C. E. Ball" <ceball at users.sf.net>
Date: 8 December 2007 00:40:11 GMT
To: pythonmac-sig at python.org
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter

>


Chris
my first comment would be that there are plenty of issues here to  
grapple with
>
> On OS X, I'd like to be able to build my own copy of Python that uses
> my own copy of Tkinter (built for X11). I've seen several posts to
> this list where people mention building python this way (e.g. [1] and
> [2] below), but I'm pretty unfamiliar with the concepts, so I wonder
> if someone could give me some more help, or point me to a place where
> there are some instructions?
>
>
> I found the only way I could get Python to build using my own tcl and
> tk was by renaming OS X's Tk and Tcl framework directories so that
> they would not be found.
It is not good to do this because anything else trying to use them  
will not find the originals.
> Is there some alteration I can make to
> python's setup.py instead?
You should be able to specify the non framework tcl and tk to the  
configure script which
you would run before setup.py do
  configure --help used to show it to be something like configure- 
with-tcl=foo configure-with-tk=bar
where foo and bar are the directories with the tcl and tk  
distributions in.
However this no longer holds ....
So whether this is correct  I'm unable to say at present.
This should not be AquaTk which has some deficiencies notably it  
doesn't include Togl or Tix
this precludes the use of a library in the standard linux  
distribution (Tix) and prevents any access
to OpenGL through Tkinter.

You could also consider using a porting framework that way though  
either way you will end up having to wrangle
3 pythons.
the 2.3.x version one shipped with OSX
the 2.5.x Framework install that brought you here and
the X11 2.x.x that you build yourself or install from Mac/Darwinports  
or Fink

This means that you have to be quite careful about tracking where and  
how you install things into the site-packages
directory of each version.
You cannot really run framework builds alongside X11 builds of  
extension libraries for the same python.

If its not heresy on this list I'd suggest getting familiar with the  
Unix  build process on Linux (in a VM sandbox if necessary)
first before (potentially) creating mayhem on your Mac. It will  
reduce the number of variables and simplify the learning
curve before having to deal with what are effectively two different  
environments that coexist under OS X.
That is OS X frameworks with  PyObjC and shared libraries with X11.
>
> I'd like to have Python use X11 rather than Aqua so that I can run
> automated (buildbot) tests of an application (that is based on Python)
> on a virtual (Xvfb) display.
>
I haven't done an X11 build recently but I did do circa 10.1/10.2 and  
it worked fine and I may be doing  it again myself over the next  
couple of weeks.
>
Ed Hartley
PS just seen your latest post IIRC and passing flags is the  
alternative to what I described above and should work unless  
something in the script is
detecting the platform and overriding the options you're passing.
Someone on this list would be able to answer that one I'm sure.

> [1] http://article.gmane.org/gmane.comp.python.apple/12394/
> [2] http://article.gmane.org/gmane.comp.python.apple/12897/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071210/dfcafa91/attachment.htm 

From ronaldoussoren at mac.com  Mon Dec 10 07:56:14 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 10 Dec 2007 07:56:14 +0100
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
In-Reply-To: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
References: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
Message-ID: <0D846FAF-59F8-429A-8D6E-F465D50E19B8@mac.com>


On 8 Dec, 2007, at 1:40, C. E. Ball wrote:

> Hi,
>
> On OS X, I'd like to be able to build my own copy of Python that uses
> my own copy of Tkinter (built for X11). I've seen several posts to
> this list where people mention building python this way (e.g. [1] and
> [2] below), but I'm pretty unfamiliar with the concepts, so I wonder
> if someone could give me some more help, or point me to a place where
> there are some instructions?

I don't know of any instructions for that, but it should be  
straightforward to build such a beast.

There is one tricky bit though: Python's build process "knows" that  
Tcl/Tk on OSX is a framework and won't even look for a unixy library  
location.  That's easy to work around though: edit setup.py and look  
for the definition of detect_tkinter. At the start of that method it  
checks if the platform is 'darwin' and does something osx-specific  
when it is. Just disable that test to get the standard unix behaviour.

That is, replace "        if (platform == 'darwin' and" by "        if  
0 and (platform == 'darwin' and".


BTW. Could you please file a bug report for this at bugs.python.org?  
It would be fairly easy to add an argument to python's configure  
script that does this automaticly. I don't have time to work on that  
right now and a bugreport would help us to remember that adding such  
an argument would be useful to people.

Ronald



From ceball at users.sf.net  Mon Dec 10 16:54:52 2007
From: ceball at users.sf.net (C. E. Ball)
Date: Mon, 10 Dec 2007 23:54:52 +0800
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
In-Reply-To: <0D846FAF-59F8-429A-8D6E-F465D50E19B8@mac.com>
References: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
	<0D846FAF-59F8-429A-8D6E-F465D50E19B8@mac.com>
Message-ID: <4e2a3a120712100754x6de20f6bka71f0a0a4b844cb@mail.gmail.com>

Hi,

Thanks for helping me out.


On Dec 10, 2007 9:02 AM, Edward Hartley <ed_hartley at mac.com> wrote:
[...]
> PS just seen your latest post IIRC and passing flags is the alternative to
> what I described above and should work unless something in the script is
> detecting the platform and overriding the options you're passing.
> Someone on this list would be able to answer that one I'm sure.

Thanks, I also think something in the script is detecting the platform
and overriding the options...



On Dec 10, 2007 2:56 PM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
[...]
> There is one tricky bit though: Python's build process "knows" that
> Tcl/Tk on OSX is a framework and won't even look for a unixy library
> location.  That's easy to work around though: edit setup.py and look
> for the definition of detect_tkinter. At the start of that method it
> checks if the platform is 'darwin' and does something osx-specific
> when it is. Just disable that test to get the standard unix behaviour.
>
> That is, replace "        if (platform == 'darwin' and" by "        if
> 0 and (platform == 'darwin' and".

Actually, I tried that early on (I commented out that 'if' statement),
but Python still seemed to end up using the framework Tk. The output
of the build appeared to indicate that the correct Tkinter files had
been found, but when I started Tkinter from Python, it looked like the
Aqua version (comparing it with the X11 version I built by renaming
the Tcl and Tk framework directories).

I guess I have two questions:
(1) How sure are you that making the change above to setup.py is
enough? If you're fairly sure it should be enough, I'll check again
with Python 2.5 from the beginning (I was using Python 2.4).
(2) How can I tell for certain which Tkinter is actually being used by
Python? I feel a bit stupid, but I can't figure out how to get a
definitive path to indicate the location! All I can do is see the
difference between X11 Tkinter and the normal Aqua one.


> BTW. Could you please file a bug report for this at bugs.python.org?

Yes, I'm happy to do that; such an argument would definitely be useful to me.


Chris

(www.topographica.org: an open-source software package for
computational modeling of neural maps)

From ceball at users.sf.net  Tue Dec 11 05:07:06 2007
From: ceball at users.sf.net (C. E. Ball)
Date: Tue, 11 Dec 2007 12:07:06 +0800
Subject: [Pythonmac-SIG] Building Python with X11 Tkinter
In-Reply-To: <4e2a3a120712100754x6de20f6bka71f0a0a4b844cb@mail.gmail.com>
References: <4e2a3a120712071640g7e475a6v552a498e5b1ae975@mail.gmail.com>
	<0D846FAF-59F8-429A-8D6E-F465D50E19B8@mac.com>
	<4e2a3a120712100754x6de20f6bka71f0a0a4b844cb@mail.gmail.com>
Message-ID: <4e2a3a120712102007m30a53c26m7488b71558673639@mail.gmail.com>

> > That is, replace "        if (platform == 'darwin' and" by "        if
> > 0 and (platform == 'darwin' and".
>
> Actually, I tried that early on (I commented out that 'if' statement),
> but Python still seemed to end up using the framework Tk. The output
[...]
> (1) How sure are you that making the change above to setup.py is
> enough? If you're fairly sure it should be enough, I'll check again
> with Python 2.5 from the beginning (I was using Python 2.4).

I apologize: what you suggested does work, in combination with passing
LDFLAGS as I described earlier.


> (2) How can I tell for certain which Tkinter is actually being used by
> Python? I feel a bit stupid, but I can't figure out how to get a
> definitive path to indicate the location! All I can do is see the
> difference between X11 Tkinter and the normal Aqua one.

I don't need an answer to this question now.


> > BTW. Could you please file a bug report for this at bugs.python.org?
>
>
> Yes, I'm happy to do that; such an argument would definitely be useful to me.

I've done it: issue 1584 at bugs.python.org.


Thanks for your help

From dfh at forestfield.co.uk  Tue Dec 11 11:06:14 2007
From: dfh at forestfield.co.uk (David Hughes)
Date: Tue, 11 Dec 2007 10:06:14 +0000
Subject: [Pythonmac-SIG] Py2app and shared libraries under Leopard
Message-ID: <475E6116.3030406@forestfield.co.uk>

I've recently been involved with Robin Becker of Reportlabs  building 
and testing  one of their extension libraries across Intel and PPC 
hardware. Built using Distutils under Leopard, the library is working 
exactly as intended/expected. However, comparing the .so file produced, 
it is under half the size of the same built using Tiger - as well as 
having the execute permissions set, so Finder reports it as a Unix 
executable instead of a document. Both versions are reported as Mach-O 
universal binaries.

$ cd 
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/

$ ls -l _render*
-rwxr-xr-x  1 forestfield  admin  244620 10 Dec 12:40 _renderPM-Leopard.so
-rw-r--r--  1 forestfield  admin  570732 10 Dec 16:38 _renderPM.so

$ file _render*
_renderPM-Leopard.so:          Mach-O universal binary with 2 architectures
_renderPM-Leopard.so (for architecture i386):    Mach-O bundle i386
_renderPM-Leopard.so (for architecture ppc):    Mach-O bundle ppc
_renderPM.so:                  Mach-O universal binary with 2 architectures
_renderPM.so (for architecture i386):    Mach-O bundle i386
_renderPM.so (for architecture ppc):    Mach-O bundle ppc

The shared libraries in PIL also show the same effects when built under 
Leopard and Tiger respectively.

When I apply py2app to an application that uses these libraries, when 
the Leopard-built versions are used, I get

ValueError: Unknown load command: 27

as detailed in the attached log file. If I replace the libraries with 
their Tiger-built counterparts, the application builds OK (under Leopard).
I installed  Xcode on Leopard using default settings. Any ideas please?

Regards,

David Hughes
Forestfield Software

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071211/69216715/attachment-0001.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: py2app_build.log
Url: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071211/69216715/attachment-0001.txt 

From zooko at zooko.com  Mon Dec 17 17:10:32 2007
From: zooko at zooko.com (zooko)
Date: Mon, 17 Dec 2007 08:10:32 -0800 (PST)
Subject: [Pythonmac-SIG] does pkg_resources think that "macosx-10.3" is
 incompatible with 10.5?
In-Reply-To: <DA84D10D-1F3B-4681-B578-7B0490A85D7D@mac.com>
References: <A567E2B2-B8E0-42DF-BCEF-60427140E207@zooko.com>
	<21A62B3A-7B6F-43AE-A3DD-03459DA637AB@mac.com>
	<DA84D10D-1F3B-4681-B578-7B0490A85D7D@mac.com>
Message-ID: <14372568.post@talk.nabble.com>


On 21 Nov, 2007, at 20:59, Ronald Oussoren wrote:



> BTW. The first part of the fix is changing '<' to '>=' in the first  
> test. That doesn't fix the issue though, the config/Makefile in  
> Apple's Python.framework isn't configured for building universal  
> binaries.
> 
> And to make matters even worse: I'm pretty sure that setuptools used  
> to know that 'fat' builds are compatible with 'i386' and 'ppc'  
> architectures (at least on OSX), but that code no longer seems to be  
> there.
> 
> I'll see if I can check in a fix for the bogus if-statement tomorrow  
> morning (both in the trunk and the 2.5 branch), that way python 2.5.2  
> will at least behave correctly. I don't know if have time to work on a  
> patch for setuptools though.
> 
> I'll have to contact PJE about universal builds vs. setuptools anyway  
> (through distutils-sig) to discuss how to deal with 4-way universal  
> eggs.
> 

What is the status on this issue?  Can I safely assume that Python 2.5.2 and
Python 2.6 will be able to produce and consume eggs correctly on Mac OS X? 
Is there a bug tracker where I can check the status of this issue?

For reference, here is the tracker entry in the allmydata.org tahoe issue
tracker:

http://allmydata.org/trac/tahoe/ticket/212

Regards,

Zooko

-- 
View this message in context: http://www.nabble.com/does-pkg_resources-think-that-%22macosx-10.3%22-is-incompatible-with-10.5--tp13865060p14372568.html
Sent from the Python - pythonmac-sig mailing list archive at Nabble.com.


From vivacarlie at gmail.com  Mon Dec 17 23:00:03 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Mon, 17 Dec 2007 16:00:03 -0600
Subject: [Pythonmac-SIG] vobject
In-Reply-To: <5C8993A2-0116-1000-BF1F-FE1AFD45468F-Webmail-10013@mac.com>
References: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
	<CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>
	<5C8993A2-0116-1000-BF1F-FE1AFD45468F-Webmail-10013@mac.com>
Message-ID: <65fadfc30712171400i6f819ee6u2dcf956f29d33914@mail.gmail.com>

But is that leopard only?

On Dec 6, 2007 3:41 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> On Thursday, December 06, 2007, at 08:34AM, "David Warde-Farley" <
> dwf at cs.toronto.edu> wrote:
> >On 5-Dec-07, at 11:36 PM, Nehemiah Dacres wrote:
> >
> >> perhaps you could point your python to the ical callendar store
> >> place (i forget where this is but its documented at apple
> >> somewhere ) and edit the ical calendar objects with this. Now you
> >> can use a well documented, programmatic interface to your ical
> >> calendars instead of using appscript.
> >
> >I've read about this before and it's a nice idea, however if I were
> >writing something for OS X I'd still want to use the application hooks
> >for iCal, just to be sure I was getting up to date data. AFAIK Apple
> >makes no guarantees about how often the calendar is flushed to disk.
> >
> >What would be neat is a bridge that reads the iCalendar using
> >appscript or something like it, and spits out VObjects (or the same
> >deal for Address Book cards), and could flush back from VObject to
> >Apple Address Book. I might consider writing the address book portion
> >when I get around to coding up an iSync conduit for my obsolete cell
> >phone.
>
> FWIW: Leopard includes API's for accessing iCal's database (the
> CalendarStore framework) and that framework is wrapped by PyObjC.
>
> Ronald
>
> >
> >David
> >_______________________________________________
> >Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> >http://mail.python.org/mailman/listinfo/pythonmac-sig
> >
> >
>



-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071217/b1aca872/attachment.htm 

From ronaldoussoren at mac.com  Tue Dec 18 08:13:30 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 18 Dec 2007 08:13:30 +0100
Subject: [Pythonmac-SIG] vobject
In-Reply-To: <65fadfc30712171400i6f819ee6u2dcf956f29d33914@mail.gmail.com>
References: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
	<CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>
	<5C8993A2-0116-1000-BF1F-FE1AFD45468F-Webmail-10013@mac.com>
	<65fadfc30712171400i6f819ee6u2dcf956f29d33914@mail.gmail.com>
Message-ID: <8EC5AAB7-2D28-468C-8BE1-45D66263693E@mac.com>


On 17 Dec, 2007, at 23:00, Nehemiah Dacres wrote:

> But is that leopard only?

Yes, that's what I wrote.

Ronald

>
>
> On Dec 6, 2007 3:41 AM, Ronald Oussoren <ronaldoussoren at mac.com>  
> wrote:
>
>
> FWIW: Leopard includes API's for accessing iCal's database (the  
> CalendarStore framework) and that framework is wrapped by PyObjC.
>
> Ronald
>
> >
> >David
> >_______________________________________________
> >Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> > http://mail.python.org/mailman/listinfo/pythonmac-sig
> >
> >
>
>
>
> -- 
>
> "lalalalala! it's not broken because I can use it"
>
> http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071218/1ca507f4/attachment.htm 

From vivacarlie at gmail.com  Tue Dec 18 17:53:39 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Tue, 18 Dec 2007 10:53:39 -0600
Subject: [Pythonmac-SIG] vobject
In-Reply-To: <8EC5AAB7-2D28-468C-8BE1-45D66263693E@mac.com>
References: <65fadfc30712052036o6b70e6dfq4409bd88e3b7e739@mail.gmail.com>
	<CDDFDBA5-7034-4194-BF5F-360417D3287B@cs.toronto.edu>
	<5C8993A2-0116-1000-BF1F-FE1AFD45468F-Webmail-10013@mac.com>
	<65fadfc30712171400i6f819ee6u2dcf956f29d33914@mail.gmail.com>
	<8EC5AAB7-2D28-468C-8BE1-45D66263693E@mac.com>
Message-ID: <65fadfc30712180853m7d950f04jbe2648d18f144ca7@mail.gmail.com>

vobject is used in the calendar server so don't have to  worry about how
update callendar store is, subscribe to the delegate.  ...  (
http://trac.calendarserver.org/projects/calendarserver/wiki/Portability)

and it's NOT leopard only.

personally, I may just skip a version until they deal with these aesthetic
issues.

On Dec 18, 2007 1:13 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> On 17 Dec, 2007, at 23:00, Nehemiah Dacres wrote:
>
> But is that leopard only?
>
>
> Yes, that's what I wrote.
>
> Ronald
>
>
>
> On Dec 6, 2007 3:41 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> >
> >
> > FWIW: Leopard includes API's for accessing iCal's database (the
> > CalendarStore framework) and that framework is wrapped by PyObjC.
> >
> > Ronald
> >
> > >
> > >David
> > >_______________________________________________
> > >Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> > > http://mail.python.org/mailman/listinfo/pythonmac-sig
> > >
> > >
> >
>
>
>
> --
>
> "lalalalala! it's not broken because I can use it"
>
>
> http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
>
>
>


-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071218/87e75892/attachment.htm 

From dfh at forestfield.co.uk  Tue Dec 18 19:48:50 2007
From: dfh at forestfield.co.uk (David Hughes)
Date: Tue, 18 Dec 2007 18:48:50 +0000
Subject: [Pythonmac-SIG] Py2app and shared libraries under Leopard
In-Reply-To: <475E6116.3030406@forestfield.co.uk>
References: <475E6116.3030406@forestfield.co.uk>
Message-ID: <47681612.8080605@forestfield.co.uk>

David Hughes wrote:
> .....Built using Distutils under Leopard, the library [/Reportlab's 
> _Render.pm]/ is working exactly as intended/expected. However, 
> comparing the .so file produced, it is under half the size of the same 
> built using Tiger [/and it generates an error when it is include in a 
> Py2app build/] ...
I posted this here about a week ago but there were no responses. Am I 
doing something so incredibly stupid that people are too polite to point 
it out??
--
David Hughes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071218/24aa51de/attachment.htm 

From robin at alldunn.com  Tue Dec 18 20:29:27 2007
From: robin at alldunn.com (Robin Dunn)
Date: Tue, 18 Dec 2007 11:29:27 -0800
Subject: [Pythonmac-SIG] Py2app and shared libraries under Leopard
In-Reply-To: <47681612.8080605@forestfield.co.uk>
References: <475E6116.3030406@forestfield.co.uk>
	<47681612.8080605@forestfield.co.uk>
Message-ID: <47681F97.8020300@alldunn.com>

David Hughes wrote:
> David Hughes wrote:
>> .....Built using Distutils under Leopard, the library [/Reportlab's 
>> _Render.pm]/ is working exactly as intended/expected. However, 
>> comparing the .so file produced, it is under half the size of the same 
>> built using Tiger [/and it generates an error when it is include in a 
>> Py2app build/] ...
> I posted this here about a week ago but there were no responses. Am I 
> doing something so incredibly stupid that people are too polite to point 
> it out??

The difference in size can probably be attributed to different default
compile/link options, I've seen seen similar 50% differences with wx
libs even on the same machine and same compiler.  Another possibility is
that the smaller one is not a universal binary for some reason.

If the error you are getting is "Unknown load command" then you need to
get a newer version of the macholib package or egg.

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!



From ronaldoussoren at mac.com  Tue Dec 18 22:20:27 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 18 Dec 2007 22:20:27 +0100
Subject: [Pythonmac-SIG] Py2app and shared libraries under Leopard
In-Reply-To: <47681F97.8020300@alldunn.com>
References: <475E6116.3030406@forestfield.co.uk>
	<47681612.8080605@forestfield.co.uk> <47681F97.8020300@alldunn.com>
Message-ID: <E1F783E4-8CA8-41AC-B8CF-318CA9C7747E@mac.com>


On 18 Dec, 2007, at 20:29, Robin Dunn wrote:

> David Hughes wrote:
>> David Hughes wrote:
>>> .....Built using Distutils under Leopard, the library [/Reportlab's
>>> _Render.pm]/ is working exactly as intended/expected. However,
>>> comparing the .so file produced, it is under half the size of the  
>>> same
>>> built using Tiger [/and it generates an error when it is include  
>>> in a
>>> Py2app build/] ...
>> I posted this here about a week ago but there were no responses. Am I
>> doing something so incredibly stupid that people are too polite to  
>> point
>> it out??
>
> The difference in size can probably be attributed to different default
> compile/link options, I've seen seen similar 50% differences with wx
> libs even on the same machine and same compiler.  Another  
> possibility is
> that the smaller one is not a universal binary for some reason.
>
> If the error you are getting is "Unknown load command" then you need  
> to
> get a newer version of the macholib package or egg.

Apple's python on Leopard doesn't build universal binaries by default.  
I've filed a bugreport for this, hopefully it will be fixed in the  
future.

In the meantime you can edit os.path.join(sys.prefix, "lib/python2.5/ 
config/Makefile") and add "-arch ppc -arch x86" to the CFLAGS and  
LDFLAGS definitions.

BTW. "file myext.so" will tell you if an extension is universal and  
which architectures it supports.

Ronald
>
>
> -- 
> Robin Dunn
> Software Craftsman
> http://wxPython.org  Java give you jitters?  Relax with wxPython!
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From cooper.me at gmail.com  Wed Dec 19 05:57:25 2007
From: cooper.me at gmail.com (Micheal Cooper)
Date: Wed, 19 Dec 2007 13:57:25 +0900
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
Message-ID: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>

Using MacPorts (installed yesterday and updated today), I installed:
  py25-psycopg2 @2.0.5.1_0 (active)
which pulls in the following as dependencies:
  postgresql81 @8.1.10_0+darwin_8 (active)
  python25 @2.5.1_4+darwin_8 (active)
then I installed:
  postgresql81-server @8.1.10_0 (active)
  subversion @1.4.5_0 (active)

It looks like things should be working, but I am getting errors when I try
to do `python manage.py runserver` as per directions on
http://www.djangoproject.com/documentation/tutorial01/

The problem seems to be psycopg2. If someone could give me some advice, I
would be most grateful.

Full error message:



Unhandled exception in thread started by <function inner_run at 0x109be30>
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/commands/runserver.py",
line 47, in inner_run
    self.validate(display_num_errors=True)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/base.py",
line 112, in validate
    num_errors = get_validation_errors(s, app)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/validation.py",
line 22, in get_validation_errors
    from django.db import models, connection
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/__init__.py",
line 17, in <module>
    backend = __import__('%s%s.base' % (_import_path,
settings.DATABASE_ENGINE), {}, {}, [''])
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 15, in <module>
    raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /usr/local/pgsql/lib/libpq.4.dylib
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so
  Reason: image not found
Validating models...
Unhandled exception in thread started by <function inner_run at 0x109ce30>
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/commands/runserver.py",
line 47, in inner_run
    self.validate(display_num_errors=True)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/base.py",
line 112, in validate
    num_errors = get_validation_errors(s, app)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/validation.py",
line 22, in get_validation_errors
    from django.db import models, connection
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/__init__.py",
line 17, in <module>
    backend = __import__('%s%s.base' % (_import_path,
settings.DATABASE_ENGINE), {}, {}, [''])
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 15, in <module>
    raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /usr/local/pgsql/lib/libpq.4.dylib
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so
  Reason: image not found
Validating models...
Unhandled exception in thread started by <function inner_run at 0x109ce30>
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/commands/runserver.py",
line 47, in inner_run
    self.validate(display_num_errors=True)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/base.py",
line 112, in validate
    num_errors = get_validation_errors(s, app)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/validation.py",
line 22, in get_validation_errors
    from django.db import models, connection
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/__init__.py",
line 17, in <module>
    backend = __import__('%s%s.base' % (_import_path,
settings.DATABASE_ENGINE), {}, {}, [''])
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 15, in <module>
    raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /usr/local/pgsql/lib/libpq.4.dylib
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so
  Reason: image not found
Validating models...
Unhandled exception in thread started by <function inner_run at 0x109ce30>
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/commands/runserver.py",
line 47, in inner_run
    self.validate(display_num_errors=True)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/base.py",
line 112, in validate
    num_errors = get_validation_errors(s, app)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/validation.py",
line 22, in get_validation_errors
    from django.db import models, connection
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/__init__.py",
line 17, in <module>
    backend = __import__('%s%s.base' % (_import_path,
settings.DATABASE_ENGINE), {}, {}, [''])
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 15, in <module>
    raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /usr/local/pgsql/lib/libpq.4.dylib
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so
  Reason: image not found





-- 
Micheal Cooper
Miyazaki, Japan (GMT+9, no DST)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071219/29cc4756/attachment-0001.htm 

From jsquintz at gmail.com  Wed Dec 19 07:05:20 2007
From: jsquintz at gmail.com (Jamie Quint)
Date: Tue, 18 Dec 2007 22:05:20 -0800
Subject: [Pythonmac-SIG] PIL on Leopard
Message-ID: <8e5825090712182205r76abe6c3r21a8828d55cdaec7@mail.gmail.com>

I am attempting to install PIL on Leopard from source, it all appears to be
working, the build summary gives an all ok (see below)

jamiequint:/usr/src/Imaging-1.1.6$ sudo python setup.py install
running install
running build
running build_py
running build_ext
--- using frameworks at /System/Library/Frameworks
--------------------------------------------------------------------
PIL 1.1.6 BUILD SUMMARY
--------------------------------------------------------------------
version       1.1.6
platform      darwin 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
              [GCC 4.0.1 (Apple Inc. build 5465)]
--------------------------------------------------------------------
--- TKINTER support ok
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
--- FREETYPE2 support ok
--------------------------------------------------------------------
To check the build, run the selftest.py script.
running build_scripts
running install_lib
creating /Library/Python/2.5/site-packages/PIL
...


However, after this if I try to convert a jpg I get the following error (I
can open the file and get info out of it, yet I cant save it).


jamiequint:/Library/Python/2.5/site-packages$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Image
>>> i = Image.open("/Users/jamiequint/Desktop/tag.jpg")
>>> i.save("blah.png")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.5/site-packages/PIL/Image.py", line 1372, in save
    self.load()
  File "/Library/Python/2.5/site-packages/PIL/ImageFile.py", line 180, in
load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "/Library/Python/2.5/site-packages/PIL/Image.py", line 375, in
_getdecoder
    raise IOError("decoder %s not available" % decoder_name)
IOError: decoder jpeg not available
>>> i.size
(1321, 816)
>>> i.format
'JPEG'
>>> i.mode
'RGB'


Any suggestions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071218/06e8fbeb/attachment.htm 

From jwt at onjapan.net  Wed Dec 19 07:19:48 2007
From: jwt at onjapan.net (Jim Tittsler)
Date: Wed, 19 Dec 2007 19:19:48 +1300
Subject: [Pythonmac-SIG] PIL on Leopard
In-Reply-To: <8e5825090712182205r76abe6c3r21a8828d55cdaec7@mail.gmail.com>
References: <8e5825090712182205r76abe6c3r21a8828d55cdaec7@mail.gmail.com>
Message-ID: <236FB38C-1859-47C0-A331-7A439EDBFF4A@onjapan.net>

On Dec 19, 2007, at 19:05, Jamie Quint wrote:

> I am attempting to install PIL on Leopard from source, it all  
> appears to be working, the build summary gives an all ok (see below)

I'm still on Tiger, but I noticed this blog posting on the subject  
just this morning:
   http://www.oreillynet.com/onlamp/blog/2007/12/ 
pil_on_leopard_or_how_i_made_p.html



-- 
Jim Tittsler     http://www.OnNZ.net/      GPG: 0x01159DB6
Python Starship  http://Starship.Python.net/crew/jwt/
Mailman IRC      irc://irc.freenode.net/#mailman




From vivacarlie at gmail.com  Wed Dec 19 15:50:59 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Wed, 19 Dec 2007 08:50:59 -0600
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
Message-ID: <65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>

perhaps you should send this to macports. you see, Mac Ports normally
installs stuff in /opt/local/bin. but that is not where this code is being
ran from according to your traceback.
"Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 15, in <module>
    raise ImproperlyConfigured("Error loading psycopg2 module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/psycopg2/_psycopg.so,
2): Library not loaded: /usr/local/pgsql/lib/libpq.4.dylib"

looks like posgresql isn't installed on the same root that django was
installed. django seems to have ben installed in
Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django,
and did not put PosgreSQL in /usr/local/pgsql/lib/libpq.4.dylib" perhaps you
need to give it the path of your database enngine. try, at the commandline
"locate postgresql81 and see where they put it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071219/b0c107b8/attachment.htm 

From kw at codebykevin.com  Wed Dec 19 16:36:56 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 19 Dec 2007 10:36:56 -0500
Subject: [Pythonmac-SIG] Problems with PythonLauncher on Leopard
Message-ID: <47693A98.5020100@codebykevin.com>

I've noticed strange behavior with PythonLauncher on Leopard (I'm using 
the standard build of MacPython 2.5.1).    The expected behavior with 
PythonLauncher is that when I double-click on a Python script, a 
Terminal window will launch and cd to the script's working directory, 
and then Python will run the script.

What's happening now is that PythonLauncher opens a Terminal window, but 
it does not change the working directory to the script's directory, and 
Python never runs the script.

Here's some output from Console:

12/19/07 10:31:16 AM Python Launcher[1467] doscript: Could not activate 
Terminal

12/19/07 10:31:16 AM Python Launcher[1467] doscript: AESend(activate): 
error -600

12/19/07 10:31:16 AM Python Launcher[1467] Exit status: -600

12/19/07 10:31:16 AM com.apple.launchd[146] 
([0x0-0x9c09c].org.python.PythonLauncher[1467]) Stray process with PGID 
equal to this dead job: PID 1469 PPID 1 Terminal
12/19/07 10:31:32 AM com.apple.launchd[1] (com.apple.dyld) Throttling 
respawn: Will start in 60 seconds

I can obviously work around this by running everything from the 
command-line, i.e. cd myscriptpath && python myscript.py, but 
PythonLauncher is supposed to do this for me. Has anyone else observed 
this kind of behavior?

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From Chris.Barker at noaa.gov  Wed Dec 19 17:33:03 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 19 Dec 2007 08:33:03 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
Message-ID: <476947BF.5070300@noaa.gov>



Nehemiah Dacres wrote:
> perhaps you should send this to macports. 

Or forget macports, install the 2.5 macpython Universal framework build 
and as many of the packages you need that you can find on:

http://pythonmac.org/packages/py25-fat/index.html

Then try to build/install the rest of the ones you need form source.

Any trouble you have, ask here -- that's the Python best supported by 
this list.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Wed Dec 19 20:10:22 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 19 Dec 2007 20:10:22 +0100
Subject: [Pythonmac-SIG] PIL on Leopard
In-Reply-To: <8e5825090712182205r76abe6c3r21a8828d55cdaec7@mail.gmail.com>
References: <8e5825090712182205r76abe6c3r21a8828d55cdaec7@mail.gmail.com>
Message-ID: <0CF100C2-B537-4EF3-AEF3-A5DCA4D5536A@mac.com>


On 19 Dec, 2007, at 7:05, Jamie Quint wrote:

> I am attempting to install PIL on Leopard from source, it all  
> appears to be working, the build summary gives an all ok (see below)

The build process is a bit to lenient to my taste, it will automaticly  
detect which C libraries are available and will adapt the build proces  
to that. To build PIL with JPEG support you'll have to download and  
install the jpeg libraries (http://www.ijg.org/).

Ronald


>
>
> jamiequint:/usr/src/Imaging- 1.1.6$ sudo python setup.py install
> running install
> running build
> running build_py
> running build_ext
> --- using frameworks at /System/Library/Frameworks
> --------------------------------------------------------------------
> PIL 1.1.6 BUILD SUMMARY
> --------------------------------------------------------------------
> version       1.1.6
> platform      darwin 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
>               [GCC 4.0.1 (Apple Inc. build 5465)]
> --------------------------------------------------------------------
> --- TKINTER support ok
> --- JPEG support ok
> --- ZLIB (PNG/ZIP) support ok
> --- FREETYPE2 support ok
> --------------------------------------------------------------------
> To check the build, run the selftest.py script.
> running build_scripts
> running install_lib
> creating /Library/Python/2.5/site-packages/PIL
> ...
>
>
> However, after this if I try to convert a jpg I get the following  
> error (I can open the file and get info out of it, yet I cant save  
> it).
>
>
> jamiequint:/Library/Python/2.5/site-packages$ python
> Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import Image
> >>> i = Image.open("/Users/jamiequint/Desktop/tag.jpg")
> >>> i.save("blah.png")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/Library/Python/2.5/site-packages/PIL/Image.py", line 1372,  
> in save
>     self.load()
>   File "/Library/Python/2.5/site-packages/PIL/ImageFile.py", line  
> 180, in load
>     d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
>   File "/Library/Python/2.5/site-packages/PIL/Image.py", line 375,  
> in _getdecoder
>     raise IOError("decoder %s not available" % decoder_name)
> IOError: decoder jpeg not available
> >>> i.size
> (1321, 816)
> >>> i.format
> 'JPEG'
> >>> i.mode
> 'RGB'
>
>
> Any suggestions?
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From Chris.Barker at noaa.gov  Wed Dec 19 23:21:13 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 19 Dec 2007 14:21:13 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
Message-ID: <47699959.9040302@noaa.gov>

Nehemiah Dacres wrote:
> so we're still not supporting Apple's shipped python?

Well, Apple does what Apples does. Every single version of python that 
they have shipped as had at least one bug (or misfeature), and they have 
never provided an update within an OS-X version. (For example, if 
nothing else, the Apple python with Leopard doesn't build Universal 
Binaries when you use setup.py)

Given all that, it's easier to just stick with an external Python that 
we, as a community, can have some control over. It's also one version 
that will run (and build extensions that run) on PPC and Intel, OS-X 
versions 10.3.9 - 10.5.*

A whole lot easier to support.

And I don't think macports is supporting Apple's Python either.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Thu Dec 20 12:35:53 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 20 Dec 2007 12:35:53 +0100
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <47699959.9040302@noaa.gov>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
Message-ID: <FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>


On 19 Dec, 2007, at 23:21, Christopher Barker wrote:

> Nehemiah Dacres wrote:
>> so we're still not supporting Apple's shipped python?

That depends on what you mean by "support" ;-)

>>
>
> Well, Apple does what Apples does. Every single version of python that
> they have shipped as had at least one bug (or misfeature), and they  
> have
> never provided an update within an OS-X version. (For example, if
> nothing else, the Apple python with Leopard doesn't build Universal
> Binaries when you use setup.py)

That's easily fixable. I'm thinking about reviving Jack's MacPython  
addons idea: a small .mpkg that will install IDLE.app, a 64-bit  
command-line interpreter and some small fixes (such as the distutiles  
one).  That should make Leopard's builtin python a lot more useable  
without requireing people to basicly install the same version of  
python that is already on their system.

My only problem in this regard is a complete lack of time to do this  
in :-(.

Ronald

From vivacarlie at gmail.com  Thu Dec 20 15:52:15 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Thu, 20 Dec 2007 08:52:15 -0600
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
Message-ID: <65fadfc30712200652r592c8226sed8e49a76cd1669e@mail.gmail.com>

I support your decision not to fully support Apple's python, and Mac Ports
uses internal distros of all supported software. (in other words. if pyhton
2.5 is a dependency, you will wind up with MacPorts' version of python at
/opt/local/bin/ and it's up to you to decide which one to use.

On Dec 20, 2007 5:35 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> On 19 Dec, 2007, at 23:21, Christopher Barker wrote:
>
> > Nehemiah Dacres wrote:
> >> so we're still not supporting Apple's shipped python?
>
> That depends on what you mean by "support" ;-)
>
> >>
> >
> > Well, Apple does what Apples does. Every single version of python that
> > they have shipped as had at least one bug (or misfeature), and they
> > have
> > never provided an update within an OS-X version. (For example, if
> > nothing else, the Apple python with Leopard doesn't build Universal
> > Binaries when you use setup.py)
>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
> command-line interpreter and some small fixes (such as the distutiles
> one).  That should make Leopard's builtin python a lot more useable
> without requireing people to basicly install the same version of
> python that is already on their system.
>
> My only problem in this regard is a complete lack of time to do this
> in :-(.
>
> Ronald
>



-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071220/18aad568/attachment.htm 

From woklist at kyngchaos.com  Thu Dec 20 16:02:28 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu, 20 Dec 2007 09:02:28 -0600
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
Message-ID: <B5277B77-C07B-4E6B-99ED-3C2DB2FE5092@kyngchaos.com>

On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:

>> never provided an update within an OS-X version. (For example, if
>> nothing else, the Apple python with Leopard doesn't build Universal
>> Binaries when you use setup.py)
>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
> command-line interpreter and some small fixes (such as the distutiles
> one).  That should make Leopard's builtin python a lot more useable
> without requireing people to basicly install the same version of
> python that is already on their system.
>
> My only problem in this regard is a complete lack of time to do this
> in :-(.
>
That would be cool.  I'm optimistic that Apple will maintain Python  
better this time around (heck, the last security update already  
included one for python, tho I didn't see what that was).

I've been thinking of trying to build a 64bit python executable  
myself, to run some non-carbon based python stuff.  Lack of time here,  
too, but it's quieting down so I may look at it soon.

> Ronald
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect



From Chris.Barker at noaa.gov  Thu Dec 20 18:30:55 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 20 Dec 2007 09:30:55 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <B5277B77-C07B-4E6B-99ED-3C2DB2FE5092@kyngchaos.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<B5277B77-C07B-4E6B-99ED-3C2DB2FE5092@kyngchaos.com>
Message-ID: <476AA6CF.3090202@noaa.gov>

William Kyngesburye wrote:
> On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:
> 
>>> never provided an update within an OS-X version. (For example, if
>>> nothing else, the Apple python with Leopard doesn't build Universal
>>> Binaries when you use setup.py)
>>
>> That's easily fixable.

Yes, it is, but so have many of the other issues in the past. The point 
is that Apple isn't likely to fix it, and if they don't then, we'll have 
a lot of questions on the mailing list about things not working, at at 
the moment, the fix required digging into the Framework and editing a 
file -- not a big deal for people like me, but a support hassle.

When I first started running OS-X (10.2, I think), Apple shipped a 
version of python (2.2, maybe) with it that I tried very hard to use. I 
really liked idea of using "built-in" tools, and it loaned a lot of 
legitimacy to my push for Python as a standard tool for our organization.

However, I had to hack at it to get distutils to build stuff right, and 
there were other issues. I finally gave up and found that it was much 
easier to install and use a newer version. I don't see that anything has 
changed. Until Apple really makes it clear that they are supporting 
Python as standard part of OS-X that can be depended on, I"ll stick with 
community built versions.

  - will they provide updates?
  - will they guarantee that future versions of OS-X have the same stuff?
  - etc.

>> I'm thinking about reviving Jack's MacPython
>> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
>> command-line interpreter and some small fixes (such as the distutiles
>> one).  That should make Leopard's builtin python a lot more useable
>> without requireing people to basicly install the same version of
>> python that is already on their system.

Disk space (and for most of us, bandwidth ) is so cheap these days that 
it's just not a big deal. Once you have to install something, what does 
it matter how big it is?

Even if we (which means Ronald, or Bob -- I don't have the time, skills 
or motivation!) do provide what is essentially a patch package, will 
folks be able to use it and py2app to build bundles that run on other 
systems? or bundles that will then run on future systems?

> I'm optimistic that Apple will maintain Python 
> better this time around (heck, the last security update already included 
> one for python, tho I didn't see what that was).

That's a good sign, but I'm not as optimistic as you. Besides, if you 
depend on Apple's python and the packages it includes, you're depending 
on a bunch of specific versions, and the odds are good that your app 
will then break when a new OS-X with a newer versions of everything 
Python comes out.

> I've been thinking of trying to build a 64bit python executable myself, 
> to run some non-carbon based python stuff.

That would be pretty cool. Are you thinking quad-universal? or just 
PPC64+Intel64? or just one architecture?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Thu Dec 20 18:31:26 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 20 Dec 2007 09:31:26 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <B5277B77-C07B-4E6B-99ED-3C2DB2FE5092@kyngchaos.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<B5277B77-C07B-4E6B-99ED-3C2DB2FE5092@kyngchaos.com>
Message-ID: <476AA6EE.4070203@noaa.gov>

William Kyngesburye wrote:
> On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:
> 
>>> never provided an update within an OS-X version. (For example, if
>>> nothing else, the Apple python with Leopard doesn't build Universal
>>> Binaries when you use setup.py)
>>
>> That's easily fixable.

Yes, it is, but so have many of the other issues in the past. The point 
is that Apple isn't likely to fix it, and if they don't then, we'll have 
a lot of questions on the mailing list about things not working, at at 
the moment, the fix required digging into the Framework and editing a 
file -- not a big deal for people like me, but a support hassle.

When I first started running OS-X (10.2, I think), Apple shipped a 
version of python (2.2, maybe) with it that I tried very hard to use. I 
really liked idea of using "built-in" tools, and it loaned a lot of 
legitimacy to my push for Python as a standard tool for our organization.

However, I had to hack at it to get distutils to build stuff right, and 
there were other issues. I finally gave up and found that it was much 
easier to install and use a newer version. I don't see that anything has 
changed. Until Apple really makes it clear that they are supporting 
Python as standard part of OS-X that can be depended on, I"ll stick with 
community built versions.

  - will they provide updates?
  - will they guarantee that future versions of OS-X have the same stuff?
  - etc.

>> I'm thinking about reviving Jack's MacPython
>> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
>> command-line interpreter and some small fixes (such as the distutiles
>> one).  That should make Leopard's builtin python a lot more useable
>> without requireing people to basicly install the same version of
>> python that is already on their system.

Disk space (and for most of us, bandwidth ) is so cheap these days that 
it's just not a big deal. Once you have to install something, what does 
it matter how big it is?

Even if we (which means Ronald, or Bob -- I don't have the time, skills 
or motivation!) do provide what is essentially a patch package, will 
folks be able to use it and py2app to build bundles that run on other 
systems? or bundles that will then run on future systems?

> I'm optimistic that Apple will maintain Python 
> better this time around (heck, the last security update already included 
> one for python, tho I didn't see what that was).

That's a good sign, but I'm not as optimistic as you. Besides, if you 
depend on Apple's python and the packages it includes, you're depending 
on a bunch of specific versions, and the odds are good that your app 
will then break when a new OS-X with a newer versions of everything 
Python comes out.

> I've been thinking of trying to build a 64bit python executable myself, 
> to run some non-carbon based python stuff.

That would be pretty cool. Are you thinking quad-universal? or just 
PPC64+Intel64? or just one architecture?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Jack.Jansen at cwi.nl  Fri Dec 21 09:48:03 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri, 21 Dec 2007 09:48:03 +0100
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
Message-ID: <5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>


On 20 dec 2007, at 12:35, Ronald Oussoren wrote:

>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
> command-line interpreter and some small fixes (such as the distutiles
> one).  That should make Leopard's builtin python a lot more useable
> without requireing people to basicly install the same version of
> python that is already on their system.


I think this would be a very good idea, even if only from a  
"political" point of view.
Even though I've been an open source developer since long before the  
word existed I find that I'm getting sick and tired of the reinvent- 
the-world attitude that is far too common in the open source community.

If I am new to Python on the Mac and I've played with Apple Python a  
little, but as soon as I want to install one little add-on module I  
have to first replace the whole existing Python with something new  
(and not directly Apple-endorsed) I might just drop out. And at the  
very least it's mightily inconvenient. Also note that the chances that  
the distutils fix or the 64-bit fix are likely to affect me are  
exactly zero (the "newcomer me" from this paragraph, not the "flesh  
and blood Jack" me:-).
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



From ronaldoussoren at mac.com  Fri Dec 21 15:42:02 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 21 Dec 2007 06:42:02 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
Message-ID: <8707ABF6-0116-1000-A1B0-6445F326E660-Webmail-10013@mac.com>

 
On Friday, December 21, 2007, at 09:48AM, "Jack Jansen" <Jack.Jansen at cwi.nl> wrote:
>
>On 20 dec 2007, at 12:35, Ronald Oussoren wrote:
>
>>
>> That's easily fixable. I'm thinking about reviving Jack's MacPython
>> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
>> command-line interpreter and some small fixes (such as the distutiles
>> one).  That should make Leopard's builtin python a lot more useable
>> without requireing people to basicly install the same version of
>> python that is already on their system.
>
>
>I think this would be a very good idea, even if only from a  
>"political" point of view.
>Even though I've been an open source developer since long before the  
>word existed I find that I'm getting sick and tired of the reinvent- 
>the-world attitude that is far too common in the open source community.
>
>If I am new to Python on the Mac and I've played with Apple Python a  
>little, but as soon as I want to install one little add-on module I  
>have to first replace the whole existing Python with something new  
>(and not directly Apple-endorsed) I might just drop out. And at the  
>very least it's mightily inconvenient. Also note that the chances that  
>the distutils fix or the 64-bit fix are likely to affect me are  
>exactly zero (the "newcomer me" from this paragraph, not the "flesh  
>and blood Jack" me:-).

Hear, hear...  It's not the replacing of python per-se that annoys me, it is
replacing it by *exactly the same version* that is annoying.

Contrary to what some people seem to think Apple does learn and is trying
to make Python as good as possible. They make mistakes, but hey they are
humans. 

A small package that fixes some small annoyances would make everyones 
lives easier.  It would also result in a system python that is arguably better
than the standard python.org tree: 64-bit support and dtrace support built-in.

Neither are currently available in the python.org tree, even when you built from
source. 

Ronald

>--
>Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
>If I can't dance I don't want to be part of your revolution -- Emma  
>Goldman
>
>
>
>

From daniellord at mac.com  Fri Dec 21 15:44:42 2007
From: daniellord at mac.com (Daniel Lord)
Date: Fri, 21 Dec 2007 06:44:42 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
Message-ID: <3D7230D1-5945-4D0B-BD9B-D6E969A1F3F7@mac.com>


On Dec 21, 2007, at 12:48 AM, Jack Jansen wrote:
> I think this would be a very good idea, even if only from a
> "political" point of view.
> Even though I've been an open source developer since long before the
> word existed I find that I'm getting sick and tired of the reinvent-
> the-world attitude that is far too common in the open source  
> community.
> If I am new to Python on the Mac and I've played with Apple Python a
> little, but as soon as I want to install one little add-on module I
> have to first replace the whole existing Python with something new
> (and not directly Apple-endorsed) I might just drop out. And at the
> very least it's mightily inconvenient. Also note that the chances that
> the distutils fix or the 64-bit fix are likely to affect me are
> exactly zero (the "newcomer me" from this paragraph, not the "flesh
> and blood Jack" me:-).

There are many who can wax more eloquently than I, maybe even  
Stallman- or Raymond-esqe about cathedrals and bazaars, on the  
material differences in the drivers behind and goals of commercial and  
open source software projects, but Jack's points about the  
isolationist tendencies and the need for "native" Python support are  
well-stated and his suggestion should be given serious consideration.  
While this community has done very well with only tacit Apple support  
(though embedding PyObjC is a bit more than tacit), we would likely  
find more support by Apple if we expand our offering to cater to the  
left half and tail of the Python adoption normal distribution. This  
would have the effect of raising Apple's awareness of the importance  
of Python on the platform. For example: I should not have to tinker  
with path settings, or worse install another a complete other Python,   
to use Python in a scriptable high-end 3D graphics modeler and  
renderer where a perfectly good one is already installed. Better  
OpenOffice Python integration and native Appscript and Python OSA  
support are others. But this means providing a reasonably rich set of  
tools that is fully accessible from the stock Python installation for  
the neophytes and apprentices as much as journeymen. I am with you Jack.

Daniel Lord


From hengist.podd at virgin.net  Fri Dec 21 22:37:22 2007
From: hengist.podd at virgin.net (has)
Date: Fri, 21 Dec 2007 21:37:22 +0000
Subject: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
Message-ID: <1841BA35-DD9E-49D2-84EE-78265E3F9F27@virgin.net>

Hi all,

Just ran into the following problem when trying to install appscript  
0.18.0 into Leopard's default Python installation via easy_install  
(setuptools 0.6c3):

has$ /usr/bin/easy_install appscript
Searching for appscript
Reading http://pypi.python.org/simple/appscript/
Reading http://appscript.sourceforge.net
Reading http://freespace.virgin.net/hamish.sanderson/appscript.html
Best match: appscript 0.18.0
Downloading http://pypi.python.org/packages/source/a/appscript/appscript-0.18.0.tar.gz#md5 
=8c013f0489349f145089c71d6d747859
Processing appscript-0.18.0.tar.gz
Running appscript-0.18.0/setup.py -q bdist_egg --dist-dir /var/folders/ 
p+/p+pBAQxKE-S81g-RmJ1K8U+++TI/-Tmp-/easy_install-7MwieU/ 
appscript-0.18.0/egg-dist-tmp-deTIQh
Traceback (most recent call last):
   File "/usr/bin/easy_install", line 8, in <module>
     load_entry_point('setuptools==0.6c7', 'console_scripts',  
'easy_install')()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1670, in  
main
     with_ei_usage(lambda:
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1659, in  
with_ei_usage
     return f()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1674, in  
<lambda>
     distclass=DistributionWithoutHelpCommands, **kw
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/core.py", line 151, in setup
     dist.run_commands()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 974, in run_commands
     self.run_command(cmd)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 994, in run_command
     cmd_obj.run()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 211, in run
     self.easy_install(spec, not self.no_deps)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 446, in  
easy_install
     return self.install_item(spec, dist.location, tmpdir, deps)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 471, in  
install_item
     dists = self.install_eggs(spec, download, tmpdir)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 655, in  
install_eggs
     return self.build_and_install(setup_script, setup_base)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 930, in  
build_and_install
     self.run_setup(setup_script, setup_base, args)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 919, in  
run_setup
     run_setup(setup_script, args)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 27, in run_setup
     lambda: execfile(
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 63, in run
     return func()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 29, in <lambda>
     {'__file__':setup_script, '__name__':'__main__'}
   File "setup.py", line 10, in <module>
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/py2app/util.py", line 9, in <module>
     import macholib.util
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/macholib/util.py", line 56, in <module>
     class writablefile(file):
TypeError: Error when calling the metaclass bases
     first argument must be callable


Two things:

1. Any ideas on why it's selecting the .tar.gz version rather than  
the .egg? (Note: the egg was built using my own Python 2.5  
installation, rather than the Apple one.)

2. I get the above traceback when easy_install tries to use the source- 
based appscript. This occurs with Leopard's own Python 2.5 and the  
Python 2.4 installation I keep around for testing purposes. Any  
guesses on what's going wrong? I'm not that familiar with setuptools  
and its error reporting leaves something to be desired, so I don't  
even know if the problem lies with it or appscript's setup.py script.



Thanks,

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org


From Jack.Jansen at cwi.nl  Fri Dec 21 23:07:29 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri, 21 Dec 2007 23:07:29 +0100
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
Message-ID: <ACF8FF1C-FF01-4F9A-981D-D2DCD9200CDD@cwi.nl>

I've been thinking a bit more about being forced to upgrade package X  
when I'm not interested, and I realised that the times it really  
bothers me are even one more step removed: if I was interested in  
package X and the website/whatever told me "don't use the current  
version of X, use the newer one" I can probably live with that.

The real problem is when I couldn't care less about package X but I'm  
really interested in Y, which uses X, and then X forcing me to upgrade  
it.

Python is in a pretty good shape right now, with well-packaged  
extension modules being compatible with a fairly wide range of Python  
installations, but please let's try and keep it that way.
--
Jack Jansen, <Jack.Jansen at cwi.nl>, 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 at noaa.gov  Sun Dec 23 09:01:03 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 23 Dec 2007 00:01:03 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <ACF8FF1C-FF01-4F9A-981D-D2DCD9200CDD@cwi.nl>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
	<ACF8FF1C-FF01-4F9A-981D-D2DCD9200CDD@cwi.nl>
Message-ID: <476E15BF.2030901@noaa.gov>

Jack Jansen wrote:
> The real problem is when I couldn't care less about package X but I'm  
> really interested in Y, which uses X, and then X forcing me to upgrade  
> it.

Just to make sure I understand -- is this an example of that:

I want to use wxPython (the most recent version). I expect to have to 
install that, but now the website tells me that I need to install the 
python.org python before I can use wxPython. Yes, that is annoying, but....

> Python is in a pretty good shape right now, with well-packaged  
> extension modules being compatible with a fairly wide range of Python  
> installations, but please let's try and keep it that way.

Keep it what way? My experience and reading tells me that if I use the 
python.org 2.5 Universal Framework, I'll get a python that will work on 
OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with 
py2app will work on those platforms, AND extensions I build with it will 
also work on all those platforms (with the same Python anyway). That's 
the state of affairs that I'm trying to keep. It appears that 
encouraging people to use Apple's python with OS-X 10.5 will break that 
state.

I don't run 10.5, but from what I've seen, it's just introduced 
complexity and questions on this mailing list, a LOT of extra complexity 
for people building binaries to distribute.

Jack Jansen wrote:
> I think this would be a very good idea, even if only from a "political" 
> point of view.

well, yes, the politics are relevant.

> Even though I've been an open source developer since long before the 
> word existed I find that I'm getting sick and tired of the 
> reinvent-the-world attitude that is far too common in the open source 
> community.

I really don't think this is re-invent the world.

> If I am new to Python on the Mac and I've played with Apple Python a 
> little, but as soon as I want to install one little add-on module I have 
> to first replace the whole existing Python with something new (and not 
> directly Apple-endorsed)

This was discussed a lot a while back, mostly on the context of what the 
common Python-on-Mac web sites should recommend to newbies.

http://wiki.python.org/moin/MacPython/PythonDistributionsForMac
"""
Mac OS X comes with a pre-installation of Python, usually one or two 
years old. This can be sufficient for some needs, but the MacPython 
community recommends installing a newer, more capable, version.
"""

seems to be what was settled on then. Maybe Apple's python really is 
good enough to be considered the "default", but I have my doubts. 
Anyway, the reason to make that recommendation up front was that it's a 
lot less bothersome to new users to say:

Want to try python? -- install this, then, when you need any extra 
packages, get them here.

Then to get them used to using the built-in one, but when you start 
doing something "real", you need to go get another one. To use your 
example, far worse than:

"as soon as I want to install one little add-on module I have  to first 
replace the whole existing Python with something new"

is

"after using Apple's python for a while, and installing a bunch of extra 
packages into it, I now discover that it won't work for my needs, and I 
have to replace not only python, but all the extra packages I had 
already installed"

Will that happen? I don't know, but I suspect it will. And frankly, once 
you're downloading and installing one thing, two isn't really a big deal 
-- unless you suffer from very limited bandwidth. OH, and it sounds like 
we're proposing asking new users to install a "Apple'sPythonFix" package 
anyway, so the ONLY difference is bandwidth, and the fact that you're 
not using the version from Apple -- is there really anyone that ONLY 
runs Apple software?

> it's mightily inconvenient. Also note that the chances that the 
> distutils fix or the 64-bit fix are likely to affect me are exactly zero 

Not so. The distutils issue effects you in two ways --

1) it's really not that rare to have to compile things -- and maybe you 
want to use py2app to distribute something.

2) You want binaries from someone else, and they aren't right, because 
they compiled them with Apple's python.


Anyway, I'd love it if Apple's Python really could meet all of our 
needs, so go prove me wrong!

Oh, and one way or another, someone should update that Wiki page for 10.5.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Sun Dec 23 16:23:06 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 23 Dec 2007 16:23:06 +0100
Subject: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
In-Reply-To: <1841BA35-DD9E-49D2-84EE-78265E3F9F27@virgin.net>
References: <1841BA35-DD9E-49D2-84EE-78265E3F9F27@virgin.net>
Message-ID: <37752E4C-80C2-43DD-B021-0D9552C9167F@mac.com>

Has,

On 21 Dec, 2007, at 22:37, has wrote:

> Hi all,
>
> Just ran into the following problem when trying to install appscript
> 0.18.0 into Leopard's default Python installation via easy_install
> (setuptools 0.6c3):
>
> has$ /usr/bin/easy_install appscript
> Searching for appscript
> Reading http://pypi.python.org/simple/appscript/
> Reading http://appscript.sourceforge.net
> Reading http://freespace.virgin.net/hamish.sanderson/appscript.html
> Best match: appscript 0.18.0
> Downloading http://pypi.python.org/packages/source/a/appscript/appscript-0.18.0.tar.gz#md5
> =8c013f0489349f145089c71d6d747859
> Processing appscript-0.18.0.tar.gz
> Running appscript-0.18.0/setup.py -q bdist_egg --dist-dir /var/ 
> folders/
> p+/p+pBAQxKE-S81g-RmJ1K8U+++TI/-Tmp-/easy_install-7MwieU/
> appscript-0.18.0/egg-dist-tmp-deTIQh
> Traceback (most recent call last):

[...]
>
> -TypeError: Error when calling the metaclass bases
>     first argument must be callable
>
>
> Two things:
>
> 1. Any ideas on why it's selecting the .tar.gz version rather than
> the .egg? (Note: the egg was built using my own Python 2.5
> installation, rather than the Apple one.)

That's a buglet in Python, fixed in what will be 2.5.2. Apple's python  
doesn't do universal binaries and setuptools doesn't know that an  
'fat' egg will do on a 'ppc' or 'i386' platform.

>
>
> 2. I get the above traceback when easy_install tries to use the  
> source-
> based appscript. This occurs with Leopard's own Python 2.5 and the
> Python 2.4 installation I keep around for testing purposes. Any
> guesses on what's going wrong? I'm not that familiar with setuptools
> and its error reporting leaves something to be desired, so I don't
> even know if the problem lies with it or appscript's setup.py script.

My guess is that this a buglet in setuptools sandboxing code. Can you  
build an egg using Apple's python and install that (that is run  
'setup.py bdist_egg' and then install that egg.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071223/b333d64b/attachment.bin 

From ronaldoussoren at mac.com  Sun Dec 23 16:44:07 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 23 Dec 2007 16:44:07 +0100
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
	Intel MacBook Pro Tiger
In-Reply-To: <476E15BF.2030901@noaa.gov>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>
	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>
	<476947BF.5070300@noaa.gov>
	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>
	<47699959.9040302@noaa.gov>
	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>
	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>
	<ACF8FF1C-FF01-4F9A-981D-D2DCD9200CDD@cwi.nl>
	<476E15BF.2030901@noaa.gov>
Message-ID: <B0D48511-D130-4799-8A8A-1A3E3DC4E834@mac.com>


On 23 Dec, 2007, at 9:01, Christopher Barker wrote:

> Jack Jansen wrote:
>> The real problem is when I couldn't care less about package X but I'm
>> really interested in Y, which uses X, and then X forcing me to  
>> upgrade
>> it.
>
> Just to make sure I understand -- is this an example of that:
>
> I want to use wxPython (the most recent version). I expect to have to
> install that, but now the website tells me that I need to install the
> python.org python before I can use wxPython. Yes, that is annoying,  
> but....

That should be a documentation bug, either that or their installer  
sucks. Any framework build of python2.5 on OSX can use extensions  
build using any other framework build of python2.5. This is by design,  
back in the old times (OSX 10.1 and python2.3 IIRC) we had some  
serious problems with that (e.g. you build an extension with one build  
of python, use it with another build and get some very hard to  
understand or debug error messages).

>
>
>> Python is in a pretty good shape right now, with well-packaged
>> extension modules being compatible with a fairly wide range of Python
>> installations, but please let's try and keep it that way.
>
> Keep it what way? My experience and reading tells me that if I use the
> python.org 2.5 Universal Framework, I'll get a python that will work  
> on
> OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with
> py2app will work on those platforms, AND extensions I build with it  
> will
> also work on all those platforms (with the same Python anyway). That's
> the state of affairs that I'm trying to keep. It appears that
> encouraging people to use Apple's python with OS-X 10.5 will break  
> that
> state.

The right way (TM) to go forward is investigate what causes these  
problems and fix them, not tell people to reinstall the same version  
of Python they already have on their system.

>
> I don't run 10.5, but from what I've seen, it's just introduced
> complexity and questions on this mailing list, a LOT of extra  
> complexity
> for people building binaries to distribute.

I've seen two types of problems:

1) Apple's build is slightly broken in that it doesn't build universal  
binaries

2) If you have both Apple's build of python and the Python.org build  
on the system people get confused

I've also found, and *fixed*, a problem in the code in distutils that  
determines if it is possible to universal binaries on the current  
platform.

>
>
> Jack Jansen wrote:
>> I think this would be a very good idea, even if only from a  
>> "political"
>> point of view.
>
> well, yes, the politics are relevant.
>
>> Even though I've been an open source developer since long before the
>> word existed I find that I'm getting sick and tired of the
>> reinvent-the-world attitude that is far too common in the open source
>> community.
>
> I really don't think this is re-invent the world.

Why do you think it isn't?   Your suggestion is just as annoying as  
Fink or MacPorts which insist on installing software I already have on  
my system.  I understand the technical reasons for doing this (it  
makes QA a bit easier), but that doesn't make it less annoying.

>
>
>> If I am new to Python on the Mac and I've played with Apple Python a
>> little, but as soon as I want to install one little add-on module I  
>> have
>> to first replace the whole existing Python with something new (and  
>> not
>> directly Apple-endorsed)
>
> This was discussed a lot a while back, mostly on the context of what  
> the
> common Python-on-Mac web sites should recommend to newbies.
>
> http://wiki.python.org/moin/MacPython/PythonDistributionsForMac
> """
> Mac OS X comes with a pre-installation of Python, usually one or two
> years old. This can be sufficient for some needs, but the MacPython
> community recommends installing a newer, more capable, version.
> """

That was true on 10.3 and 10.4, but not on 10.5. The version on 10.5  
is the bleeding edge of the stable branch and includes features that  
the Python.org tree does not (dtrace support).

>
>
> seems to be what was settled on then. Maybe Apple's python really is
> good enough to be considered the "default", but I have my doubts.
> Anyway, the reason to make that recommendation up front was that  
> it's a
> lot less bothersome to new users to say:
>
> Want to try python? -- install this, then, when you need any extra
> packages, get them here.
>
>
> Then to get them used to using the built-in one, but when you start
> doing something "real", you need to go get another one. To use your
> example, far worse than:
>
> "as soon as I want to install one little add-on module I have  to  
> first
> replace the whole existing Python with something new"
>
> is
>
> "after using Apple's python for a while, and installing a bunch of  
> extra
> packages into it, I now discover that it won't work for my needs,  
> and I
> have to replace not only python, but all the extra packages I had
> already installed"
>
>
> Will that happen? I don't know, but I suspect it will. And frankly,  
> once
> you're downloading and installing one thing, two isn't really a big  
> deal
> -- unless you suffer from very limited bandwidth. OH, and it sounds  
> like 
> we're proposing asking new users to install a "Apple'sPythonFix"  
> package
> anyway, so the ONLY difference is bandwidth, and the fact that you're
> not using the version from Apple -- is there really anyone that ONLY
> runs Apple software?

I'm proposing an "MacPythonAddons" package that will install some  
useful stuff on top of Apple's stuff. That will include a number of  
small bugfixes, but mostly additional software that will make life  
easier for new developers (such as an .app bundle for IDLE).

Note that I don't want to get into a discussion on the quality of  
IDLE. As far as I'm concerned it is good enough for casual development  
and I haven't found a proper replacement yet.

The important bit in my proposal is trying to improve things, instead  
of whining how Apple has always provided a broken Python installation  
and will forever do so.

>
>
>> it's mightily inconvenient. Also note that the chances that the
>> distutils fix or the 64-bit fix are likely to affect me are exactly  
>> zero
>
> Not so. The distutils issue effects you in two ways --
>
> 1) it's really not that rare to have to compile things -- and maybe  
> you
> want to use py2app to distribute something.
>
> 2) You want binaries from someone else, and they aren't right, because
> they compiled them with Apple's python.
>
>
> Anyway, I'd love it if Apple's Python really could meet all of our
> needs, so go prove me wrong!

Apple's python won't work 10.4, but who cares. Several prominent  
developers of software that runs on MacOSX have stated that they will  
no longer develop software that targets 10.4 or earlier and I agree  
with them.

OSX 10.5 is a major leap forward for the platform, and more so for  
developers than for end users.

>
>
> Oh, and one way or another, someone should update that Wiki page for  
> 10.5.

Be my guest, I don't have time for it.

Ronald

>
>
> -Chris
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071223/e47f63fa/attachment.bin 

From nicholas.cole at gmail.com  Sun Dec 23 18:26:28 2007
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Sun, 23 Dec 2007 17:26:28 +0000
Subject: [Pythonmac-SIG] Tk 8.5 and leopard.
Message-ID: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>

I've just seen that a new version of Tk has been released, and the
screenshots suggest that it will blend in much better on the mac platoform.
What is going to be the best way of installing the new Tk and a version of
python that can use it, without upsetting apple's python install (which I'm
using with Xcode...)

I hope that question makes sense...

Best wishes,

N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071223/a38e65d2/attachment.htm 

From robin at alldunn.com  Mon Dec 24 00:05:48 2007
From: robin at alldunn.com (Robin Dunn)
Date: Sun, 23 Dec 2007 15:05:48 -0800
Subject: [Pythonmac-SIG] newbie Mac switcher trying to set up django on
 Intel MacBook Pro Tiger
In-Reply-To: <B0D48511-D130-4799-8A8A-1A3E3DC4E834@mac.com>
References: <f91aa3d0712182057m6d719ffeu359c9bf038cb3d73@mail.gmail.com>	<65fadfc30712190650o3b19c79ap16a003aa14853d36@mail.gmail.com>	<476947BF.5070300@noaa.gov>	<65fadfc30712191042sc5ff9d9m374066e12f7d3245@mail.gmail.com>	<47699959.9040302@noaa.gov>	<FDA8EE79-4F37-43DA-BDCE-614830D68BBC@mac.com>	<5CD83E48-A39B-481C-85CD-92B095EA5637@cwi.nl>	<ACF8FF1C-FF01-4F9A-981D-D2DCD9200CDD@cwi.nl>	<476E15BF.2030901@noaa.gov>
	<B0D48511-D130-4799-8A8A-1A3E3DC4E834@mac.com>
Message-ID: <476EE9CC.3050004@alldunn.com>

Ronald Oussoren wrote:
> 
> On 23 Dec, 2007, at 9:01, Christopher Barker wrote:
> 
>> Jack Jansen wrote:
>>> The real problem is when I couldn't care less about package X but I'm
>>> really interested in Y, which uses X, and then X forcing me to upgrade
>>> it.
>>
>> Just to make sure I understand -- is this an example of that:
>>
>> I want to use wxPython (the most recent version). I expect to have to
>> install that, but now the website tells me that I need to install the
>> python.org python before I can use wxPython. Yes, that is annoying, 
>> but....
> 
> That should be a documentation bug, either that or their installer 
> sucks.

Yeah, I'm working on it.  The current (and only, I think) issue with the
installer is that it is pretty dumb about what path it chooses to
install to.


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!



From noah.gift at gmail.com  Mon Dec 24 18:43:02 2007
From: noah.gift at gmail.com (Noah Gift)
Date: Mon, 24 Dec 2007 12:43:02 -0500
Subject: [Pythonmac-SIG] GHOP tasks for PyObjc2
Message-ID: <e91cc0270712240943y3272a31bg8bdc3c7b0d783182@mail.gmail.com>

I am not sure if everyone here is aware of GHOP:
http://groups.google.com/group/ghop-python?hl=en

I have noticed a bunch of people asking for PyObjc2 documentation and
examples.  How does making these tasks apart of GHOP sound?

Noah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071224/0f492314/attachment.htm 

From ronaldoussoren at mac.com  Wed Dec 26 12:34:00 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 26 Dec 2007 12:34:00 +0100
Subject: [Pythonmac-SIG] GHOP tasks for PyObjc2
In-Reply-To: <e91cc0270712240943y3272a31bg8bdc3c7b0d783182@mail.gmail.com>
References: <e91cc0270712240943y3272a31bg8bdc3c7b0d783182@mail.gmail.com>
Message-ID: <515DDDF2-1CD6-4323-809B-58945291B60F@mac.com>


On 24 Dec, 2007, at 18:43, Noah Gift wrote:

> I am not sure if everyone here is aware of GHOP:
>
> http://groups.google.com/group/ghop-python?hl=en
>
> I have noticed a bunch of people asking for PyObjc2 documentation  
> and examples.  How does making these tasks apart of GHOP sound?

What's GHOP? The link doesn't give a description of it. ... slightly  
later .. Ah, it a summer-of-code for high-school students.

There's loads of examples for PyObjC, and I have to admit too little  
documentation. What especially needs to be done is make the existing  
material better available, which probably entails replacing the  
current PyObjC website by something better.

If someone feels like mentoring, or working on,  this (I barely have  
time to do that myself). I do have some (technical) requirements:

1) It should be easy to integrate documentation from the PyObjC source  
distribution into the website

The source distribution should preferably be the master location for  
documents, but it should definitely not be
necessary to maintain documentation in two seperate locations.

2) A better way to browse and download examples

The PyObjC website currently has a page with links to PyObjC 1.x  
examples in the repository. I would like to replace
that by something more dynamic, and with options to download archives  
(such as zipfiles) with examples. A bit like Apple's ADC site (<http://developer.apple.com/samplecode/Transformed_Image/index.html 
 >).

As with the main documentation this part of the website should be  
generated from the source tree.

3) I'd prefer a website without PHP and without the dogsnake icon. It  
should be possible to generate a simple website as the pyobjc one  
using something like genshi.

Note that the site runs on sourceforge, that means that PHP is the  
only way to do server-side logic.

4) I'm not interested in a wiki unless there are volunteers for  
hunting down spam.

As mentioned earlier on I don't have time to mentor this, but am  
available to provide some feedback.

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071226/16cbb3db/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071226/16cbb3db/attachment.bin 

From noah.gift at gmail.com  Wed Dec 26 19:52:09 2007
From: noah.gift at gmail.com (Noah Gift)
Date: Wed, 26 Dec 2007 13:52:09 -0500
Subject: [Pythonmac-SIG] GHOP tasks for PyObjc2
In-Reply-To: <515DDDF2-1CD6-4323-809B-58945291B60F@mac.com>
References: <e91cc0270712240943y3272a31bg8bdc3c7b0d783182@mail.gmail.com>
	<515DDDF2-1CD6-4323-809B-58945291B60F@mac.com>
Message-ID: <e91cc0270712261052x3d952233la231f3b71a32521c@mail.gmail.com>

Ronald,
I think this sounds like a good plan.  I will see what I can do about making
tasks out of this list for GHOP.  Will report back shortly.

Noah

On Dec 26, 2007 6:34 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> On 24 Dec, 2007, at 18:43, Noah Gift wrote:
>
> I am not sure if everyone here is aware of GHOP:
> http://groups.google.com/group/ghop-python?hl=en
>
> I have noticed a bunch of people asking for PyObjc2 documentation and
> examples.  How does making these tasks apart of GHOP sound?
>
>
> What's GHOP? The link doesn't give a description of it. ... slightly later
> .. Ah, it a summer-of-code for high-school students.
>
> There's loads of examples for PyObjC, and I have to admit too little
> documentation. What especially needs to be done is make the existing
> material better available, which probably entails replacing the current
> PyObjC website by something better.
>
> If someone feels like mentoring, or working on,  this (I barely have time
> to do that myself). I do have some (technical) requirements:
>
> 1) It should be easy to integrate documentation from the PyObjC source
> distribution into the website
>
> The source distribution should preferably be the master location for
> documents, but it should definitely not be
> necessary to maintain documentation in two seperate locations.
>
> 2) A better way to browse and download examples
>
> The PyObjC website currently has a page with links to PyObjC 1.x examples
> in the repository. I would like to replace
> that by something more dynamic, and with options to download archives
> (such as zipfiles) with examples. A bit like Apple's ADC site (<
> http://developer.apple.com/samplecode/Transformed_Image/index.html>).
>
> As with the main documentation this part of the website should be
> generated from the source tree.
>
> 3) I'd prefer a website without PHP and without the dogsnake icon. It
> should be possible to generate a simple website as the pyobjc one using
> something like genshi.
>
> Note that the site runs on sourceforge, that means that PHP is the only
> way to do server-side logic.
>
> 4) I'm not interested in a wiki unless there are volunteers for hunting
> down spam.
>
> As mentioned earlier on I don't have time to mentor this, but am available
> to provide some feedback.
>
> Ronald
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071226/1bb1ed13/attachment.htm 

From rowen at cesmail.net  Thu Dec 27 06:28:00 2007
From: rowen at cesmail.net (Russell E. Owen)
Date: Wed, 26 Dec 2007 21:28:00 -0800
Subject: [Pythonmac-SIG] Tk 8.5 and leopard.
References: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>
Message-ID: <rowen-1B9209.21280026122007@news.gmane.org>

In article 
<a5c3d8350712230926t3e9ade87k1b8733b1df852f44 at mail.gmail.com>,
 "Nicholas Cole" <nicholas.cole at gmail.com> wrote:

> I've just seen that a new version of Tk has been released, and the
> screenshots suggest that it will blend in much better on the mac platoform.
> What is going to be the best way of installing the new Tk and a version of
> python that can use it, without upsetting apple's python install (which I'm
> using with Xcode...)
> 
> I hope that question makes sense...

Well...I do not normally recommend messing with stuff in System but if 
you are willing to risk it then you can try Keven Walzer's _tkinter.so. 
I put a copy up here (with his kind permission):
<http://www.astro.washington.edu/rowen/python/tkinter_for_tcl8.5.zip>
along with brief installation instructions that assume you are using a 
user-installed Python, so you'll have to adapt them accordingly.

A more cautious approach would be to install a new copy of Python (it'll 
go into /Library/Frameworks) and modify that.

Please let us know how it goes.

-- Russell


From ronaldoussoren at mac.com  Thu Dec 27 11:48:34 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 27 Dec 2007 11:48:34 +0100
Subject: [Pythonmac-SIG] Tk 8.5 and leopard.
In-Reply-To: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>
References: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>
Message-ID: <98E12BCF-411A-4818-9A52-CEC21A2FEF4E@mac.com>


On 23 Dec, 2007, at 18:26, Nicholas Cole wrote:

> I've just seen that a new version of Tk has been released, and the  
> screenshots suggest that it will blend in much better on the mac  
> platoform.
>
> What is going to be the best way of installing the new Tk and a  
> version of python that can use it, without upsetting apple's python  
> install (which I'm using with Xcode...)
>
> I hope that question makes sense...

There were some messages about issues between tkinter and tcl/tk on  
python-dev (subject "Tkinter problems with Tcl/Tk 8.5"). I have no  
idea if those are resolved.

Ronald


>
> Best wishes,
>
> N
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071227/ba3d7378/attachment.bin 

From kw at codebykevin.com  Thu Dec 27 17:27:11 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Thu, 27 Dec 2007 11:27:11 -0500
Subject: [Pythonmac-SIG] Tk 8.5 and leopard.
In-Reply-To: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>
References: <a5c3d8350712230926t3e9ade87k1b8733b1df852f44@mail.gmail.com>
Message-ID: <4773D25F.9080301@codebykevin.com>

Nicholas Cole wrote:
> I've just seen that a new version of Tk has been released, and the
> screenshots suggest that it will blend in much better on the mac platoform.
> What is going to be the best way of installing the new Tk and a version of
> python that can use it, without upsetting apple's python install (which I'm
> using with Xcode...)
> 

Here's what I did:

1. Remove my installations of Tcl/Tk 8.4.x from /Library/Frameworks.
2. Build Tcl/Tk 8.5 from source and install in /Library/Frameworks.
3. Download the source code for Python 2.5.1. In "setup.py," comment out 
/System/Library as a place to search for Tcl/Tk--this will force Python 
to link to the installation of Tcl/Tk 8.5 in /Library/Frameworks.
4. Build and install. Python should work with Tk 8.5.

I should point out that the nicer screenshots for Tk are a new widget 
set, Tile/Themed Tk, which are part of the Tk core. However, they have 
to be explicitly called, and there is currenly no official support for 
them in Python's Tkinter module. I maintain a wrapper at 
http://tkinter.unpythonic.net/wiki/TileWrapper that lets you load the 
themed widgets, but I am not the original author and as I cannot reach 
the original author, it's unlikely this module will be included in Tkinter.

Other have also pointed out that Python with TK 8.5 generates a lot of 
fork/exec error messages in Console, and I can confirm this. (Bugs filed 
at python.org.)  I'm not sure if this is a problem or not--I haven't 
observed any performance problems with Python/Tkinter 8.5.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From ralarson at pacific.net  Thu Dec 27 20:53:39 2007
From: ralarson at pacific.net (rob)
Date: Thu, 27 Dec 2007 11:53:39 -0800
Subject: [Pythonmac-SIG] Let's get upgrade instructions right
Message-ID: <6B398C49-B4B5-11DC-B777-00112476C4C2@pacific.net>

Short version:  OS 10.3 (pre 3.9) users are being officially and  
wrongly advised to install a 10.4-and-later package that breaks their  
stock Python

Long version:
The Python on the Mac download page
	(http://www.python.org/download/mac/)
correctly recognizes the under-the-hood kinship of OSX 10.3.9 with  
10.4, giving one upgrade link for those versions.  It  also seems to  
recognize the differences between them on the one hand and pre-10.3.9  
versions of 10.3 on the other, when it covers the "Panther" case in a  
separate paragraph.  It suggests a two step installation process  
beginning with TclTkAqua, followed by a different link to an updated  
Python (Universal-MacPython-2.4.3-2006-04-07.dmg)

The PROBLEM seems to be that this is bad advice.  I followed it with my  
10.3.7 system and got a (classic, as it turned out) error:

dyld:  
/Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/ 
Contents/MacOS/Python can't open library: /usr/lib/libstdc++.6.dylib   
(No such file or directory, errno = 2)
Trace/BPT trap

It seems libstdc++.6.dylib was never a part of the earlier OS releases,  
and the lack of it is apparently the classic manifestation of  
application version incompatibility across the surprisingly wide divide  
circa-10.4.  In other words, the offered 2.4.3 release (not so much  
python itself, I guess, as a couple of Mac apps associated with this  
package) seems to have a "10.4 or later" requirement.

Shouldn't the community act promptly to fix this problem (or at least  
stamp out this frustrating, time-wasting misinformation?)  Anyone know  
who to call?

-Robert





* (don't you hate those cat names; I can never keep them straight  
without a scorecard).


From tuckers4all911 at yahoo.co.uk  Fri Dec 28 22:45:57 2007
From: tuckers4all911 at yahoo.co.uk (david odey)
Date: Fri, 28 Dec 2007 21:45:57 +0000 (GMT)
Subject: [Pythonmac-SIG] codes
Message-ID: <881634.84605.qm@web23406.mail.ird.yahoo.com>

please send me relevant codes for beginners
   


ALWAYS THERE FOR YOU
       
---------------------------------
 Sent from Yahoo! &#45; a smarter inbox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20071228/091bc1aa/attachment.htm 

From hengist.podd at virgin.net  Mon Dec 31 14:43:19 2007
From: hengist.podd at virgin.net (has)
Date: Mon, 31 Dec 2007 13:43:19 +0000
Subject: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
In-Reply-To: <37752E4C-80C2-43DD-B021-0D9552C9167F@mac.com>
References: <1841BA35-DD9E-49D2-84EE-78265E3F9F27@virgin.net>
	<37752E4C-80C2-43DD-B021-0D9552C9167F@mac.com>
Message-ID: <9E1E9264-D03A-4168-A3E9-E6C96A5BA442@virgin.net>

(Profuse apologies for the late reply...)

On 23 Dec 2007, at 15:23, Ronald Oussoren wrote:

>> 1. Any ideas on why it's selecting the .tar.gz version rather than
>> the .egg? (Note: the egg was built using my own Python 2.5
>> installation, rather than the Apple one.)
>
> That's a buglet in Python, fixed in what will be 2.5.2. Apple's  
> python doesn't do universal binaries and setuptools doesn't know  
> that an 'fat' egg will do on a 'ppc' or 'i386' platform.

OK, ta. Any advice on creating .eggs that will work for 10.5's brain- 
damaged Python install, both for PPC and i386? (While I have 10.4 on  
both PPC and i386, I have 10.5 on i386 only.)


>> 2. I get the above traceback when easy_install tries to use the  
>> source-
>> based appscript. This occurs with Leopard's own Python 2.5 and the
>> Python 2.4 installation I keep around for testing purposes. Any
>> guesses on what's going wrong? I'm not that familiar with setuptools
>> and its error reporting leaves something to be desired, so I don't
>> even know if the problem lies with it or appscript's setup.py script.
>
> My guess is that this a buglet in setuptools sandboxing code. Can  
> you build an egg using Apple's python and install that (that is run  
> 'setup.py bdist_egg' and then install that egg.


The following seems to work ok:

cd appscript-0.18.0
/usr/bin/python setup.py bdist_egg
cd dist
/usr/bin/easy_install appscript*

Many thanks,

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org


From ronaldoussoren at mac.com  Mon Dec 31 15:09:06 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 31 Dec 2007 15:09:06 +0100
Subject: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
In-Reply-To: <9E1E9264-D03A-4168-A3E9-E6C96A5BA442@virgin.net>
References: <1841BA35-DD9E-49D2-84EE-78265E3F9F27@virgin.net>
	<37752E4C-80C2-43DD-B021-0D9552C9167F@mac.com>
	<9E1E9264-D03A-4168-A3E9-E6C96A5BA442@virgin.net>
Message-ID: <05E4CBF0-2278-4557-91CC-2B126D728817@mac.com>


On 31 Dec, 2007, at 14:43, has wrote:

> (Profuse apologies for the late reply...)
>
> On 23 Dec 2007, at 15:23, Ronald Oussoren wrote:
>
>>> 1. Any ideas on why it's selecting the .tar.gz version rather than
>>> the .egg? (Note: the egg was built using my own Python 2.5
>>> installation, rather than the Apple one.)
>>
>> That's a buglet in Python, fixed in what will be 2.5.2. Apple's  
>> python doesn't do universal binaries and setuptools doesn't know  
>> that an 'fat' egg will do on a 'ppc' or 'i386' platform.
>
> OK, ta. Any advice on creating .eggs that will work for 10.5's brain- 
> damaged Python install, both for PPC and i386? (While I have 10.4 on  
> both PPC and i386, I have 10.5 on i386 only.)

Patching the Makefile for python is probably the easiest way, that is  
add '-arch i386 -arch ppc' to BASECFLAGS and LDFLAGS and set  
UNIVERSALSDK to '/' (otherwise the architecture will be wrong). You  
might also have to patch distutils to work around a bug in there.

>
>
>
>>> 2. I get the above traceback when easy_install tries to use the  
>>> source-
>>> based appscript. This occurs with Leopard's own Python 2.5 and the
>>> Python 2.4 installation I keep around for testing purposes. Any
>>> guesses on what's going wrong? I'm not that familiar with setuptools
>>> and its error reporting leaves something to be desired, so I don't
>>> even know if the problem lies with it or appscript's setup.py  
>>> script.
>>
>> My guess is that this a buglet in setuptools sandboxing code. Can  
>> you build an egg using Apple's python and install that (that is run  
>> 'setup.py bdist_egg' and then install that egg.
>
>
> The following seems to work ok:
>
> cd appscript-0.18.0
> /usr/bin/python setup.py bdist_egg
> cd dist
> /usr/bin/easy_install appscript*

You might want to ask on distutils-sig at python.org about this.

Ronald
>
>
> Many thanks,
>
> has
> -- 
> http://appscript.sourceforge.net
> http://rb-appscript.rubyforge.org
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071231/d0579de6/attachment.bin