From bryanabsmith at gmail.com  Mon Feb  2 05:42:59 2009
From: bryanabsmith at gmail.com (Bryan Smith)
Date: Sun, 1 Feb 2009 23:42:59 -0500
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
Message-ID: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>

Hi Everyone,

I am trying out a simple wx program from a book and anytime I try and run
the code, the wxFrame flashes open and closes immediately. This is
frustrating as the code is essentially the same as in the book. Here is the
code for your viewing pleasure:

import wx

class wxTest():

    def __init__(self):
        mainApp = wx.App()

        mainFrame = wx.Frame(None)
        mainButton = wx.Button(mainFrame)
        mainFrame.show()

        mainApp.MainLoop()

if __name__ == "__main__":
    w = wxTest()

What am I missing here? BTW, I have tried this with python 2.5 (with default
wx) and python 2.6 (wx version 2.8.9.1) and no dice.

Thanks in advance.

Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090201/97160bd9/attachment.htm>

From codyprecord at gmail.com  Mon Feb  2 05:50:51 2009
From: codyprecord at gmail.com (Cody Precord)
Date: Sun, 1 Feb 2009 22:50:51 -0600
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
Message-ID: <EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>

Hello,

On Feb 1, 2009, at 10:42 PM, Bryan Smith wrote:

> Hi Everyone,
>
> I am trying out a simple wx program from a book and anytime I try  
> and run the code, the wxFrame flashes open and closes immediately.  
> This is frustrating as the code is essentially the same as in the  
> book. Here is the code for your viewing pleasure:
>
> import wx
>
> class wxTest():
>
>     def __init__(self):
>         mainApp = wx.App()
>
>         mainFrame = wx.Frame(None)
>         mainButton = wx.Button(mainFrame)
>         mainFrame.show()
>

Should be mainFrame.Show() <- UPPER case S.

To see the traceback of errors you should create the app object with  
wx.App(False) to disable redirection of output, so tracebacks will be  
printed to the console.


Cody


From bryanabsmith at gmail.com  Mon Feb  2 06:02:34 2009
From: bryanabsmith at gmail.com (Bryan Smith)
Date: Mon, 2 Feb 2009 00:02:34 -0500
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
	<EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
Message-ID: <f49ad29d0902012102r7c3a87c8h26131462bc7a7c1@mail.gmail.com>

Oh my, I feel kind of dumb. I can't believe I spent time stewing over that.
Thanks!

On Sun, Feb 1, 2009 at 11:50 PM, Cody Precord <codyprecord at gmail.com> wrote:

> Hello,
>
> On Feb 1, 2009, at 10:42 PM, Bryan Smith wrote:
>
>  Hi Everyone,
>>
>> I am trying out a simple wx program from a book and anytime I try and run
>> the code, the wxFrame flashes open and closes immediately. This is
>> frustrating as the code is essentially the same as in the book. Here is the
>> code for your viewing pleasure:
>>
>> import wx
>>
>> class wxTest():
>>
>>    def __init__(self):
>>        mainApp = wx.App()
>>
>>        mainFrame = wx.Frame(None)
>>        mainButton = wx.Button(mainFrame)
>>        mainFrame.show()
>>
>>
> Should be mainFrame.Show() <- UPPER case S.
>
> To see the traceback of errors you should create the app object with
> wx.App(False) to disable redirection of output, so tracebacks will be
> printed to the console.
>
>
> Cody
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090202/e3eec7fc/attachment.htm>

From robin at alldunn.com  Mon Feb  2 06:47:50 2009
From: robin at alldunn.com (Robin Dunn)
Date: Sun, 01 Feb 2009 21:47:50 -0800
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
Message-ID: <49868906.6050003@alldunn.com>

Bryan Smith wrote:
> Hi Everyone,
> 
> I am trying out a simple wx program from a book and anytime I try and 
> run the code, the wxFrame flashes open and closes immediately. This is 
> frustrating as the code is essentially the same as in the book. Here is 
> the code for your viewing pleasure:
> 
> import wx
> 
> class wxTest():
>    
>     def __init__(self):
>         mainApp = wx.App()
>        
>         mainFrame = wx.Frame(None)
>         mainButton = wx.Button(mainFrame)
>         mainFrame.show()
>        
>         mainApp.MainLoop()
>        
> if __name__ == "__main__":
>     w = wxTest()
> 
> What am I missing here? 

Show is spelled with a capital S.  If you pass redirect=False to the 
wx.App constructor then you'll be better able to see any problems that 
happen in the initialization code.


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


From pdorange at mac.com  Mon Feb  2 06:55:17 2009
From: pdorange at mac.com (Pierre-Alain Dorange)
Date: Mon, 2 Feb 2009 06:55:17 +0100
Subject: [Pythonmac-SIG] Multiple version of the same module
References: <1iu3wrx.134legbn0zteuN%pdorange@mac.com>
	<497E086F.7030408@noaa.gov>
Message-ID: <1iui0iu.1ues8i8io88ysN%pdorange@mac.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> I know I haven't really given you the answer, but hopefully some hints
> to so you can figure out your options.

It really helpful, i understand better the global way it's handle.
Now i'll do some experiences.

Thanks
-- 
Pierre-Alain Dorange
<http://microwar.sourceforge.net/>


From janssen at parc.com  Mon Feb  2 17:58:28 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 08:58:28 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Message-ID: <73365.1233593908@parc.com>

I'm thinking that the right thing to do about rocket-in-the-dock should
be to change the Info.plist of Python.app, to include the setting
"LSUIElement: 1".  Here's the doc from Apple:

``LSUIElement (String). If this key is set to '1', Launch Services runs
the application as an agent application. Agent applications do not
appear in the Dock or in the Force Quit window. Although they typically
run as background applications, they can come to the foreground to
present a user interface if desired. A click on a window belonging to an
agent application brings that application forward to handle events.The
Dock and loginwindow are two applications that run as agent
applications.''

It seems to me that this is what we want for the Python interpreter
proper.  Applications (like IDLE) that are indeed proper foreground apps
can always call TransformProcessType() to override this setting and get
a dock icon for themselves.

Bill

From Chris.Barker at noaa.gov  Mon Feb  2 19:06:05 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 02 Feb 2009 10:06:05 -0800
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
	<EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
Message-ID: <4987360D.4050100@noaa.gov>

Cody Precord wrote:
> To see the traceback of errors you should create the app object with 
> wx.App(False) to disable redirection of output, so tracebacks will be 
> printed to the console.

I thought Robin said that this default was going to be changed, so that 
newbies would have this issue less -- what happened to that?

-oh well, I guess we'll just keep answering it!

-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  Mon Feb  2 19:09:19 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 02 Feb 2009 10:09:19 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <73365.1233593908@parc.com>
References: <73365.1233593908@parc.com>
Message-ID: <498736CF.2010905@noaa.gov>

Bill Janssen wrote:
> It seems to me that this is what we want for the Python interpreter
> proper.

could be. It sounds promising.

>  Applications (like IDLE) that are indeed proper foreground apps
> can always call TransformProcessType() to override this setting and get
> a dock icon for themselves.

Could you change it in the info.plist of a py2app'ed app also? I"d 
suggest that that be default in py2app. You kind of need to use py2app 
(or similar) to get an app to "act right" in the GUI anyway.

-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 janssen at parc.com  Mon Feb  2 19:27:09 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 10:27:09 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <498736CF.2010905@noaa.gov>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
Message-ID: <75297.1233599229@parc.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> Bill Janssen wrote:
> > It seems to me that this is what we want for the Python interpreter
> > proper.
> 
> could be. It sounds promising.
> 
> >  Applications (like IDLE) that are indeed proper foreground apps
> > can always call TransformProcessType() to override this setting and get
> > a dock icon for themselves.
> 
> Could you change it in the info.plist of a py2app'ed app also? I"d
> suggest that that be default in py2app. You kind of need to use py2app
> (or similar) to get an app to "act right" in the GUI anyway.

Yes, that sounds like a good idea to me.  I've never used py2app; does
it include a private copy of Python?

Bill

From Chris.Barker at noaa.gov  Mon Feb  2 19:49:52 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 02 Feb 2009 10:49:52 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <75297.1233599229@parc.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com>
Message-ID: <49874050.7090309@noaa.gov>

Bill Janssen wrote:
> Yes, that sounds like a good idea to me.  I've never used py2app; does
> it include a private copy of Python?

yes and no:

yes, if you run it with the non-apple python

no, if you run it with Apple's system python (which I think is next to 
useless, frankly -- Apple does not keep the system python consistent 
between versions)

In any case, it does include a info.plist, and it may include a 
different launch stub, so setting LSUIElement = 1 may work in either case.

-CHB



-- 
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 janssen at parc.com  Mon Feb  2 21:53:43 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 12:53:43 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <49874050.7090309@noaa.gov>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
Message-ID: <77379.1233608023@parc.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> Bill Janssen wrote:
> > Yes, that sounds like a good idea to me.  I've never used py2app; does
> > it include a private copy of Python?
> 
> yes and no:
> 
> yes, if you run it with the non-apple python
> 
> no, if you run it with Apple's system python (which I think is next to
> useless, frankly -- Apple does not keep the system python consistent
> between versions)
> 
> In any case, it does include a info.plist, and it may include a
> different launch stub, so setting LSUIElement = 1 may work in either
> case.

Sounds reasonable, then.  Set LSUIElement=1 in the Python.app Info.plist,
and other apps that use python can set it differently if they wish.

Bill

From nad at acm.org  Mon Feb  2 22:05:15 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 02 Feb 2009 13:05:15 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
References: <73365.1233593908@parc.com>
Message-ID: <nad-AC5408.13051502022009@news.gmane.org>

In article <73365.1233593908 at parc.com>, Bill Janssen <janssen at parc.com> 
wrote:

> I'm thinking that the right thing to do about rocket-in-the-dock should
> be to change the Info.plist of Python.app, to include the setting
> "LSUIElement: 1".

There's also LSBackgroundOnly.  That might be even more appropriate.  
But OTOH ...

> It seems to me that this is what we want for the Python interpreter
> proper.  Applications (like IDLE) that are indeed proper foreground apps
> can always call TransformProcessType() to override this setting and get
> a dock icon for themselves.

... setting it does have the side effect of making IDLE's menus 
disappear when launched from the command line (bin/idle).  (Launching 
via IDLE.app is unaffected.)  It also has the effect of removing the 
default Tcl/Tk-supplied menu bar for Tkinter programs; try running the 
turtleDemo, for instance.  Those programs lose Copy/Paste/Cut and the 
Quit, though the app does quit if you click the red window close button.  
Perhaps tkinter can call TPT.

I'm poking in that area at the moment and will be submitting a number of 
patches for 3.x and 2.x real soon now.  I'll try to whip something up in 
the next few days and report back.

One thing the background settings doesn't seem to change is the 
regression test (subprocess) that brings up the Application Failed 
dialog.  But I haven't had time to look at that one in detail yet.

Have you tried this with appscript?

-- 
 Ned Deily,
 nad at acm.org


From janssen at parc.com  Mon Feb  2 22:22:49 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 13:22:49 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <nad-AC5408.13051502022009@news.gmane.org>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
Message-ID: <77657.1233609769@parc.com>

Ned Deily <nad at acm.org> wrote:

> In article <73365.1233593908 at parc.com>, Bill Janssen <janssen at parc.com> 
> wrote:
> 
> > I'm thinking that the right thing to do about rocket-in-the-dock should
> > be to change the Info.plist of Python.app, to include the setting
> > "LSUIElement: 1".
> 
> There's also LSBackgroundOnly.  That might be even more appropriate.  
> But OTOH ...

Yes, I'm thinking that, too.  I'm running my system Python with that
set, and it seems to fix my various problems.

For others following along, here's the pointer to the Apple docs:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html

> ... setting it does have the side effect of making IDLE's menus 
> disappear when launched from the command line (bin/idle).  (Launching 
> via IDLE.app is unaffected.)

Fascinating.  But I don't think that's fatal -- shouldn't users be using
IDLE.app?

> It also has the effect of removing the 
> default Tcl/Tk-supplied menu bar for Tkinter programs; try running the 
> turtleDemo, for instance.  Those programs lose Copy/Paste/Cut and the 
> Quit, though the app does quit if you click the red window close button.  
> Perhaps tkinter can call TPT.

Indeed.  Given that there's already a "#ifdef TK_AQUA" section in
Modules/_tkinter.c:init_tkinter(), I'd think that would be a fine place
to put a call to TransformProcessType.  That would probably make IDLE's
menus reappear when launched from the command-line, too.

> I'm poking in that area at the moment and will be submitting a number of 
> patches for 3.x and 2.x real soon now.  I'll try to whip something up in 
> the next few days and report back.

I'll review them.

> One thing the background settings doesn't seem to change is the 
> regression test (subprocess) that brings up the Application Failed 
> dialog.  But I haven't had time to look at that one in detail yet.
> 
> Have you tried this with appscript?

Yes.  My appscript scanning app is working fine with LSBackgroundOnly set,
and no rocket in the dock.  I can logout, the various Python processes are
terminated fine.

Bill

From nad at acm.org  Mon Feb  2 22:49:08 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 02 Feb 2009 13:49:08 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<77657.1233609769@parc.com>
Message-ID: <nad-97D8D4.13490802022009@news.gmane.org>

In article <77657.1233609769 at parc.com>, Bill Janssen <janssen at parc.com> 
wrote:
> Ned Deily <nad at acm.org> wrote:
> > In article <73365.1233593908 at parc.com>, Bill Janssen <janssen at parc.com> 
> > wrote:
> > > I'm thinking that the right thing to do about rocket-in-the-dock should
> > > be to change the Info.plist of Python.app, to include the setting
> > > "LSUIElement: 1".
> > There's also LSBackgroundOnly.  That might be even more appropriate.  
> > But OTOH ...
> Yes, I'm thinking that, too.  I'm running my system Python with that
> set, and it seems to fix my various problems.
> 
> For others following along, here's the pointer to the Apple docs:
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Art
> icles/PListKeys.html
> 
> > ... setting it does have the side effect of making IDLE's menus 
> > disappear when launched from the command line (bin/idle).  (Launching 
> > via IDLE.app is unaffected.)
> 
> Fascinating.

IDLE.app goes to some lengths to convince OS X that it is executing 
under its own app bundle even though it is running the interpreter from 
the framework Python.app executable (more execve trickery) so the 
Python.app Info.plist settings don't apply.  BTW, IDLE.app is also 
broken in 3.x but I think I have that all sorted out now.

> But I don't think that's fatal -- shouldn't users be using
> IDLE.app?

Either way is supposed to work although there have been some 
discrepancies in menu behavior that I've sorted out.
 
> > It also has the effect of removing the 
> > default Tcl/Tk-supplied menu bar for Tkinter programs; try running the 
> > turtleDemo, for instance.  Those programs lose Copy/Paste/Cut and the 
> > Quit, though the app does quit if you click the red window close button.  
> > Perhaps tkinter can call TPT.
> 
> Indeed.  Given that there's already a "#ifdef TK_AQUA" section in
> Modules/_tkinter.c:init_tkinter(), I'd think that would be a fine place
> to put a call to TransformProcessType.  That would probably make IDLE's
> menus reappear when launched from the command-line, too.

Yes..
 
> > I'm poking in that area at the moment and will be submitting a number of 
> > patches for 3.x and 2.x real soon now.  I'll try to whip something up in 
> > the next few days and report back.
> I'll review them.

Good.  I still have a couple of regressions to understand before I'm 
ready to submit them.  My goal is to be able to more easily produce 
clean 3.x and 2.x Mac installers. 

> > One thing the background settings doesn't seem to change is the 
> > regression test (subprocess) that brings up the Application Failed 
> > dialog.  But I haven't had time to look at that one in detail yet.
> > 
> > Have you tried this with appscript?
> 
> Yes.  My appscript scanning app is working fine with LSBackgroundOnly set,
> and no rocket in the dock.  I can logout, the various Python processes are
> terminated fine.

Progress!

-- 
 Ned Deily,
 nad at acm.org


From Chris.Barker at noaa.gov  Tue Feb  3 00:09:36 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 02 Feb 2009 15:09:36 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <nad-AC5408.13051502022009@news.gmane.org>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
Message-ID: <49877D30.8010004@noaa.gov>

Ned Deily wrote:
>> I'm thinking that the right thing to do about rocket-in-the-dock should
>> be to change the Info.plist of Python.app, to include the setting
>> "LSUIElement: 1".
> 
> There's also LSBackgroundOnly.  That might be even more appropriate.  

I doubt it -- the whole point of this mess was to allow apps full-on 
desktop access.

Maybe we just need to return to the old python vs. pythonw distinction, 
but with a different default -- have a python-no-gui option.

However, These changes don't seem to make any difference with my wx 
tests - I suppose wx could be calling:

>> TransformProcessType() to override this setting and get
>> a dock icon for themselves.

Or I'm editing my info.plist wrong!

> ... setting it does have the side effect of making IDLE's menus 
> disappear when launched from the command line (bin/idle).

This is no OK -- it may be OK for IDLE itself, but when people are 
testing an debugging GUI apps (TK, or wx, or....) they should be able to 
start a simple script at the command line without any restrictions.


-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 janssen at parc.com  Tue Feb  3 00:20:33 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 15:20:33 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <49877D30.8010004@noaa.gov>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov>
Message-ID: <81404.1233616833@parc.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> Ned Deily wrote:
> >> I'm thinking that the right thing to do about rocket-in-the-dock should
> >> be to change the Info.plist of Python.app, to include the setting
> >> "LSUIElement: 1".
> >
> > There's also LSBackgroundOnly.  That might be even more appropriate.  
> 
> I doubt it -- the whole point of this mess was to allow apps full-on
> desktop access.

Setting LSBackgroundOnly doesn't prevent that, it just sets the default.

> Maybe we just need to return to the old python vs. pythonw
> distinction, but with a different default -- have a python-no-gui
> option.

I don't believe we need to.

> > ... setting it does have the side effect of making IDLE's menus
> > disappear when launched from the command line (bin/idle).
> 
> This is no OK -- it may be OK for IDLE itself, but when people are
> testing an debugging GUI apps (TK, or wx, or....) they should be able
> to start a simple script at the command line without any restrictions.

Sure, "open myapp.app".  But if you follow the conversation a bit
further, I think we've found a place to enable that for _tkinter.

Bill

From Chris.Barker at noaa.gov  Tue Feb  3 01:08:37 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 02 Feb 2009 16:08:37 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <81404.1233616833@parc.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com>
Message-ID: <49878B05.5010908@noaa.gov>

Bill Janssen wrote:
> Setting LSBackgroundOnly doesn't prevent that, it just sets the default.

  I don't understand -- what default? just the behavior when the app 
starts, but then it can still open windows, etc?

>> when people are
>> testing an debugging GUI apps (TK, or wx, or....) they should be able
>> to start a simple script at the command line without any restrictions.
> 
> Sure, "open myapp.app". 

I meant without an app bundle -- just a raw python script.

 > But if you follow the conversation a bit
> further, I think we've found a place to enable that for _tkinter.

Does it require a change to _tkinter? If so, then all the GUI toolkits 
(OK, all three...) would have to be changed for this to work, which 
doesn't sound good.

-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 janssen at parc.com  Tue Feb  3 01:29:37 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 16:29:37 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <49878B05.5010908@noaa.gov>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov>
Message-ID: <83446.1233620977@parc.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> Bill Janssen wrote:
> > Setting LSBackgroundOnly doesn't prevent that, it just sets the default.
> 
>  I don't understand -- what default? just the behavior when the app
> starts, but then it can still open windows, etc?

Chris, if you followed the thread, you'll know that what's happening is
that the Python.app app is being promoted to a "full app", without any
provision for behaving like a "full app".  In particular, it doesn't
participate in the various shutdown handshakes, and thus prevents logout
or shutdown.  This is pernicious.

What Ned and I are discussing is whether setting it to be, by default, a
different kind of app, would be a better idea.  It's not clear to me yet
whether LSBackgroundOnly or LSUIElement would be a better idea, but it
seems that one of them would be a good idea.

In either case, it can still open windows, etc.  Though if it were going
to do so, the Apple guidelines suggest it should call
TransformProcessType() before doing so.

> >> when people are
> >> testing an debugging GUI apps (TK, or wx, or....) they should be able
> >> to start a simple script at the command line without any restrictions.
> >
> > Sure, "open myapp.app". 
> 
> I meant without an app bundle -- just a raw python script.

Yes, I think that can be supported, too.

> > But if you follow the conversation a bit
> > further, I think we've found a place to enable that for _tkinter.
> 
> Does it require a change to _tkinter?

Don't know.  Let's see how Ned's patches work.

> If so, then all the GUI toolkits
> (OK, all three...) would have to be changed for this to work, which
> doesn't sound good.

But only tkinter is part of the Python distribution, I believe.  Of
course, whoever supports the various non-standard GUI toolkits might
also want to make changes, if necessary.  Of course, that's a pretty
standard thing that most third-party packages have to do when a new
version of Python is released, so I don't think it's a big deal.

Bill

From robin at alldunn.com  Tue Feb  3 02:48:17 2009
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 02 Feb 2009 17:48:17 -0800
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <4987360D.4050100@noaa.gov>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>	<EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
	<4987360D.4050100@noaa.gov>
Message-ID: <4987A261.1080909@alldunn.com>

Christopher Barker wrote:
> Cody Precord wrote:
>> To see the traceback of errors you should create the app object with 
>> wx.App(False) to disable redirection of output, so tracebacks will be 
>> printed to the console.
> 
> I thought Robin said that this default was going to be changed, so that 
> newbies would have this issue less -- what happened to that?

I didn't think it would be a good idea to change a default like this 
between two 2.8.x releases, but it's already changed in the 2.9 source tree.


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


From robin at alldunn.com  Tue Feb  3 02:59:35 2009
From: robin at alldunn.com (Robin Dunn)
Date: Mon, 02 Feb 2009 17:59:35 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <83446.1233620977@parc.com>
References: <73365.1233593908@parc.com>	<nad-AC5408.13051502022009@news.gmane.org>	<49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com>	<49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com>
Message-ID: <4987A507.9040103@alldunn.com>

Bill Janssen wrote:
> But only tkinter is part of the Python distribution, I believe.  Of
> course, whoever supports the various non-standard GUI toolkits might
> also want to make changes, if necessary.  Of course, that's a pretty
> standard thing that most third-party packages have to do when a new
> version of Python is released, so I don't think it's a big deal.

I have no problem adding a call to TransformProcessType (or whatever 
will be needed) to wxPython's startup code.  I think it's safe to assume 
that if wx is being imported then the process should be promoted to a 
full desktop app.  Since this requirement will appear in some specific 
version of Python it will be easy to make the API call be conditionally 
compiled.


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


From janssen at parc.com  Tue Feb  3 03:47:25 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 2 Feb 2009 18:47:25 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4987A507.9040103@alldunn.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com>
Message-ID: <86233.1233629245@parc.com>

Robin Dunn <robin at alldunn.com> wrote:

> Bill Janssen wrote:
> > But only tkinter is part of the Python distribution, I believe.  Of
> > course, whoever supports the various non-standard GUI toolkits might
> > also want to make changes, if necessary.  Of course, that's a pretty
> > standard thing that most third-party packages have to do when a new
> > version of Python is released, so I don't think it's a big deal.
> 
> I have no problem adding a call to TransformProcessType (or whatever 
> will be needed) to wxPython's startup code.  I think it's safe to assume 
> that if wx is being imported then the process should be promoted to a 
> full desktop app.

Not really -- that's why Apple has these three classes of application.

I'd suggest that promotion to LSUIElement (agent application) by the
toolkit is probably right, but I'd suggest that you only promote to full
app by actually having an app bundle that overrides the default
Info.plist.

Bill

From hraban at fiee.net  Tue Feb  3 09:10:43 2009
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Tue, 3 Feb 2009 09:10:43 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <86233.1233629245@parc.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
Message-ID: <1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>

Am 2009-02-03 um 03:47 schrieb Bill Janssen:
> I'd suggest that promotion to LSUIElement (agent application) by the
> toolkit is probably right, but I'd suggest that you only promote to  
> full
> app by actually having an app bundle that overrides the default
> Info.plist.


Sorry for chirping in as a non-expert...

If I understood you right, then any GUI app would behave different as  
app bundle or standalone.

That would make the development of GUI apps unnecessary complicated  
(it takes a while to "compile" an app bundle, and they're rather heavy).

Most of *my* wxPython-based (actually dabo-based) tools don't even  
need to be an app bundle - doubleclicking some .py file is mostly  
enough. But I wouldn't like to loose some GUI functionality.


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





From ronaldoussoren at mac.com  Tue Feb  3 14:29:19 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:29:19 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <75297.1233599229@parc.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com>
Message-ID: <E4B39686-95AD-40D2-9B10-4701E2270027@mac.com>


On 2 Feb, 2009, at 19:27, Bill Janssen wrote:

> Christopher Barker <Chris.Barker at noaa.gov> wrote:
>
>> Bill Janssen wrote:
>>> It seems to me that this is what we want for the Python interpreter
>>> proper.
>>
>> could be. It sounds promising.
>>
>>> Applications (like IDLE) that are indeed proper foreground apps
>>> can always call TransformProcessType() to override this setting  
>>> and get
>>> a dock icon for themselves.
>>
>> Could you change it in the info.plist of a py2app'ed app also? I"d
>> suggest that that be default in py2app. You kind of need to use  
>> py2app
>> (or similar) to get an app to "act right" in the GUI anyway.
>
> Yes, that sounds like a good idea to me.  I've never used py2app; does
> it include a private copy of Python?

The application bundles that py2app builds don't use Python.app, but  
can include a copy of relevant parts of the Python.framework.

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/20090203/baeb2fea/attachment.bin>

From ronaldoussoren at mac.com  Tue Feb  3 14:33:42 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:33:42 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <77379.1233608023@parc.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
	<77379.1233608023@parc.com>
Message-ID: <F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>


On 2 Feb, 2009, at 21:53, Bill Janssen wrote:
>>
>>
>> In any case, it does include a info.plist, and it may include a
>> different launch stub, so setting LSUIElement = 1 may work in either
>> case.
>
> Sounds reasonable, then.  Set LSUIElement=1 in the Python.app  
> Info.plist,
> and other apps that use python can set it differently if they wish.

Does this actually solve the problem you want to fix? Have you looked  
into what causes the icon to occur into the doc in the first place?  
What are possible side effects of setting this property?

I'm definitly -1 on changes this flag before Python 2.7 and 3.1, and  
before these questions are answered. If the flag gets added the reason  
for it needs to be documented, to avoid it getting ripped out later on.

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/20090203/d83e93ca/attachment.bin>

From ronaldoussoren at mac.com  Tue Feb  3 14:35:39 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:35:39 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <nad-97D8D4.13490802022009@news.gmane.org>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <77657.1233609769@parc.com>
	<nad-97D8D4.13490802022009@news.gmane.org>
Message-ID: <A202645D-6D85-44F1-9049-81B4F7650197@mac.com>

>
> IDLE.app goes to some lengths to convince OS X that it is executing
> under its own app bundle even though it is running the interpreter  
> from
> the framework Python.app executable (more execve trickery) so the
> Python.app Info.plist settings don't apply.  BTW, IDLE.app is also
> broken in 3.x but I think I have that all sorted out now.

It should be fixed in the 3.1 branch. I've spent about half a day to  
fix issues in IDLE because some helpful sole had applied "fixes" that  
broke idle unless you installed newer version of the Tcl/Tk framework.

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/20090203/52501dc4/attachment.bin>

From ronaldoussoren at mac.com  Tue Feb  3 14:44:35 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:44:35 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
Message-ID: <4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>


On 3 Feb, 2009, at 9:10, Henning Hraban Ramm wrote:

>
> Most of *my* wxPython-based (actually dabo-based) tools don't even  
> need to be an app bundle - doubleclicking some .py file is mostly  
> enough. But I wouldn't like to loose some GUI functionality.

IMHO running the script shouldn't be the default action for .py files,  
ever. I have two reason's for that: (1) most .py files I run into are  
just source code instead of scripts and shouldn't be executed but  
opened in an editor, and (2) this makes it way to easy to accidently  
execute a random python script that you've downloaded from the internet.

I'm seriously wondering if having "Python Launcher.app" is a good  
idea, and if we shouldn't scrap it entirely. If building full app  
bundles using py2app is too much of a burden we could look into  
providing an easier and more lightweight way to build such bundles.   
The fully standalone bundles that py2app creates are very useful, but  
I definitely see the need for very thin .app bundles as well.

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/20090203/1ff265a3/attachment-0001.bin>

From ronaldoussoren at mac.com  Tue Feb  3 15:01:07 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 15:01:07 +0100
Subject: [Pythonmac-SIG] Py2app -- where is canonical repository,
 what version is current?
In-Reply-To: <FB3C818A-2D2B-4EAF-8FF4-12365C91D2C1@integrateddevcorp.com>
References: <496506CC.30708@strout.net>
	<9B972470-594E-4787-827A-3566446EE246@keystonewood.com>
	<4965151F.7010500@strout.net> <49651C86.7080306@noaa.gov>
	<49653A6A.3070805@strout.net> <4965421E.5080405@noaa.gov>
	<49657DCF.8030204@strout.net>
	<nad-11DB2B.20492107012009@news.gmane.org>
	<49661363.1000305@strout.net> <4966439B.6030406@noaa.gov>
	<FB3C818A-2D2B-4EAF-8FF4-12365C91D2C1@integrateddevcorp.com>
Message-ID: <27B8C63A-485B-493B-8193-3ADA0021C614@mac.com>


On 14 Jan, 2009, at 2:47, s s wrote:

> I've been trying to figure out where the _real_ current Py2app is.

AFAIK this is the current home:

    http://svn.pythonmac.org/py2app/py2app/trunk

>
> I really need to add some things (compiling xib -> nib, for example)  
> to build my project and I'd prefer to start with something to which  
> I could actually contribute my changes.

Patches for that would be greatly appricated. Feel free to send  
patches to me, I have commit access to the repository.

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/20090203/d3b1f55e/attachment.bin>

From ronaldoussoren at mac.com  Tue Feb  3 14:22:40 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:22:40 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <73365.1233593908@parc.com>
References: <73365.1233593908@parc.com>
Message-ID: <50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>


On 2 Feb, 2009, at 17:58, Bill Janssen wrote:

> I'm thinking that the right thing to do about rocket-in-the-dock  
> should
> be to change the Info.plist of Python.app, to include the setting
> "LSUIElement: 1".  Here's the doc from Apple:
>
> ``LSUIElement (String). If this key is set to '1', Launch Services  
> runs
> the application as an agent application. Agent applications do not
> appear in the Dock or in the Force Quit window. Although they  
> typically
> run as background applications, they can come to the foreground to
> present a user interface if desired. A click on a window belonging  
> to an
> agent application brings that application forward to handle events.The
> Dock and loginwindow are two applications that run as agent
> applications.''
>
> It seems to me that this is what we want for the Python interpreter
> proper.  Applications (like IDLE) that are indeed proper foreground  
> apps
> can always call TransformProcessType() to override this setting and  
> get
> a dock icon for themselves.

I don't agree.  Python.app is as it is to make it possible to run  
simple GUI scripts from the command-line, if I understand the  
LSUIElement document correctly the setting you propose would make it  
impossible to use "python sometkscript.py" to run a simple GUI script.

IMHO the best way to get rid of the Rocket icon is to investigate what  
causes the icon to appear and to look for workarounds for that. The  
icon should only occur when the application (e.g. python script)  
communicates with the window server.

Ronald
>
>
> Bill
> _______________________________________________
> 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/20090203/50f85f54/attachment.bin>

From ronaldoussoren at mac.com  Tue Feb  3 14:27:58 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 14:27:58 +0100
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
Message-ID: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>

Hi,

I'm going to Pycon this year and I'm wondering if anyone is interested  
in doing a MacPython related sprint afterwards. Possible topics:

* Investigate OSX-integration issues (such as the "rocket icon" that  
sometimes appears)

* Get Py2app development going again

* Packaging 3th-party extensions (especially those using non-system C  
libraries) for OSX. That is, how to do the package collection on  
pythonmac.org correctly.

* PyObjC

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/20090203/bfc504d9/attachment.bin>

From hengist.podd at virgin.net  Tue Feb  3 16:53:27 2009
From: hengist.podd at virgin.net (has)
Date: Tue, 3 Feb 2009 15:53:27 +0000
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
Message-ID: <146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>

Bill Janssen wrote:

> Chris, if you followed the thread, you'll know that what's happening  
> is
> that the Python.app app is being promoted to a "full app", without any
> provision for behaving like a "full app".  In particular, it doesn't
> participate in the various shutdown handshakes, and thus prevents  
> logout
> or shutdown.  This is pernicious.

No more pernicious than a similarly written AppleScript applet. If a  
Python script needs to respond to external desktop-level events, it  
should create its own event loop and drive its main logic off that  
event loop. 'while 1: do_everything()' just doesn't cut it in any  
event-driven environment.

As for automatically promoting scripts that require Window Manager  
access, the current behaviour is the correct one. It is more important  
that a script should succeed than be elegant. Elegance is nice to  
have, but irrelevant if the thing won't even launch. This is why the  
old python/pythonw distinction was done away with: the default choice  
(python) ensured that some scripts would fail. Now all scripts succeed.

The problem as it relates to py-appscript is that py-appscript doesn't  
need WM access, but the OS promotes it anyway as a side-effect of  
calling certain Carbon APIs from within a .app bundle. The script  
ought to run as a regular *nix process, responding to standard *nix  
signals as needed, but the OS frustrates that. Annoying, but tweaking  
the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a  
solution, it's a kludge - one that will take us back to the bad old  
days where some scripts automatically fail when run with 'python'.

The correct solution would be for Apple to make their APIs more  
selective about upgrading the process when it doesn't need to be, but  
I doubt it's something that's important to them so don't hold your  
breath. The alternative is for Python to provide a 'pythonb' (where  
'b' stands for 'background') alternative to the default 'python'  
interpreter that scripts can use when they know they don't need WM  
access. And if you eventually want to get to the point of having only  
a single 'python' interpreter, you could start pushing the Tk, wx,  
etc. folks to add their own code for upgrading the process at startup,  
and then do away with the .app bundle in a few more years once you can  
be confident that you aren't going to break any scripts by doing so.

...

The other thing I will suggest is that somebody figures out a patch  
for appscript that replaces the current Process Manager calls with  
calls of equivalent functionality that do not cause the OS to upgrade  
the process. I _do_not_ have time to work on this problem myself (I am  
up to my ears in RL commitments), but I'll be delighted to incorporate  
any contributed patch that I'm satisfied won't break any of  
appscript's existing behaviour. It must be doable: Leopard's Scripting  
Bridge manages to avoid triggering the upgrade process, and I'm  
assuming (though have not checked) that it also targets processes by  
pid.

Regards,

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From janssen at parc.com  Tue Feb  3 17:46:42 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 08:46:42 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
Message-ID: <93629.1233679602@parc.com>

Henning Hraban Ramm <hraban at fiee.net> wrote:

> But I wouldn't like to loose some GUI functionality.

I'm sure that's true.  But I think the change I'm proposing needn't
cause any negative effects.

I've lost the ability to log out, and would like that back!

Bill

From janssen at parc.com  Tue Feb  3 17:49:01 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 08:49:01 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
Message-ID: <93649.1233679741@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> if I understand the
> LSUIElement document correctly the setting you propose would make it
> impossible to use "python sometkscript.py" to run a simple GUI script.

Then you misunderstand either LSUIElement, or the discussion so far.
What we'd like to do is to retain that capability.

Please read the Apple document I referenced earlier to get an idea of
what the three different classes of application are.  In any case, you
can always "promote" an app to a heavier-weight presence; what Apple
doesn't give us an interface for is to "demote" the app if it's been
promoted by accident.

Bill

From janssen at parc.com  Tue Feb  3 17:53:02 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 08:53:02 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
	<77379.1233608023@parc.com>
	<F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>
Message-ID: <93738.1233679982@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> 
> On 2 Feb, 2009, at 21:53, Bill Janssen wrote:
> >>
> >>
> >> In any case, it does include a info.plist, and it may include a
> >> different launch stub, so setting LSUIElement = 1 may work in either
> >> case.
> >
> > Sounds reasonable, then.  Set LSUIElement=1 in the Python.app
> > Info.plist,
> > and other apps that use python can set it differently if they wish.
> 
> Does this actually solve the problem you want to fix?

Yes.

> Have you looked
> into what causes the icon to occur into the doc in the first place?

According to Hengist:

> > Perhaps it's not the OS "upgrading" the process, but rather some
> > code in some extension calling "TransformProcessType"
> 
> It's the Carbon Process Manager. (There's no good reason for it to do
> so, but hey, I didn't write the thing.)

Do we have the sources for that, do you know?

> What are possible side effects of setting this property?

See the Apple doc I referenced earlier.

I'm going to set this flag (LSUIElement) in the system Python of every
Mac at PARC I can get my hands on, so we'll get some idea of the
effects.  I encourage others on this list to also set it, and see what
kind of effects you notice.  So far, my experience is positive.

Bill

From janssen at parc.com  Tue Feb  3 17:54:36 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 08:54:36 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
Message-ID: <93756.1233680076@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> > Most of *my* wxPython-based (actually dabo-based) tools don't even
> > need to be an app bundle - doubleclicking some .py file is mostly
> > enough. But I wouldn't like to loose some GUI functionality.
> 
> IMHO running the script shouldn't be the default action for .py files,
> ever. I have two reason's for that: (1) most .py files I run into are
> just source code instead of scripts and shouldn't be executed but
> opened in an editor, and (2) this makes it way to easy to accidently
> execute a random python script that you've downloaded from the
> internet.

Yes, I agree.

> I'm seriously wondering if having "Python Launcher.app" is a good
> idea, and if we shouldn't scrap it entirely. If building full app
> bundles using py2app is too much of a burden we could look into
> providing an easier and more lightweight way to build such bundles.
> The fully standalone bundles that py2app creates are very useful, but
> I definitely see the need for very thin .app bundles as well.

Interesting idea.  What's the lightest thing that's an app, anyway?

Bill

From janssen at parc.com  Tue Feb  3 18:03:28 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 09:03:28 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
Message-ID: <93806.1233680608@parc.com>

has <hengist.podd at virgin.net> wrote:

> Annoying, but tweaking
> the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
> solution, it's a kludge - one that will take us back to the bad old
> days where some scripts automatically fail when run with 'python'.

*Right now*, some scripts fail when run with "python".  My scripts :-).

Look, setting LSUIElement still allows access to the WM -- that's what
it's for:

``LSUIElement (String). If this key is set to '1', Launch Services runs
the application as an agent application. Agent applications do not
appear in the Dock or in the Force Quit window. Although they typically
run as background applications, they can come to the foreground to
present a user interface if desired. A click on a window belonging to an
agent application brings that application forward to handle events.''

I'm *only* suggesting this for Python.app -- other Python-based apps,
like IDLE.app, that desire a dock icon can still have a different
Info.plist.

For that matter, even if we set LSBackgroundOnly, you'd still have
access to the WM -- my appscript-based "while True" loop runs fine when
I set this flag.

The key is that you can always make the process more "heavyweight", but
you can't go in the other direction.  So Python should start as low as
possible, and work up as necessary.

Bill

From Chris.Barker at noaa.gov  Tue Feb  3 18:08:41 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:08:41 -0800
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
In-Reply-To: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
References: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
Message-ID: <49887A19.50304@noaa.gov>

Ronald Oussoren wrote:
> I'm going to Pycon this year and I'm wondering if anyone is interested 
> in doing a MacPython related sprint afterwards.

There is about a 50% chance that I'll be going.


  Possible topics:
> * Investigate OSX-integration issues (such as the "rocket icon" that 
> sometimes appears)

yes, though I know nothing about it!

> * Get Py2app development going again

Absolutely! really key!

> * Packaging 3th-party extensions (especially those using non-system C 
> libraries) for OSX. That is, how to do the package collection on 
> pythonmac.org correctly.

also good, though it seems the desire for a package collection has 
dwindled -- or is the community just waiting for some leadership to get 
it going again?

> * PyObjC

not my thing -- but good stuff.

-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 janssen at parc.com  Tue Feb  3 18:08:03 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 09:08:03 PST
Subject: [Pythonmac-SIG] setting LSUIElement in Python.app Info.plist
Message-ID: <93915.1233680883@parc.com>

I have to say, I find the somewhat uninformed resistance to this idea
incredible.  It's an *idea*, folks, not a patch.  It can't hit OS X in
any form till 10.7, which is well over a year away.  Relax -- try it
out, read the docs, and report back.  Let's *find out* what the effects
of doing this would be, not speculate about them.

Bill

From ronaldoussoren at mac.com  Tue Feb  3 18:18:36 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 18:18:36 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93756.1233680076@parc.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
	<93756.1233680076@parc.com>
Message-ID: <6BEEF715-BFC6-4A4C-9EDE-84355C028B5C@mac.com>


On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
>
>> I'm seriously wondering if having "Python Launcher.app" is a good
>> idea, and if we shouldn't scrap it entirely. If building full app
>> bundles using py2app is too much of a burden we could look into
>> providing an easier and more lightweight way to build such bundles.
>> The fully standalone bundles that py2app creates are very useful, but
>> I definitely see the need for very thin .app bundles as well.
>
> Interesting idea.  What's the lightest thing that's an app, anyway?
>

AFAIK an executable + Info.plist + icon file (plus the right directory  
structure). The executable can be shell-script on Leopard, but a  
simple executable would IMHO be better.  One way to structure such an  
executable is to read the name of the actual script to execute from  
the Info.plist (using a custom key) and then use the standard Python C- 
API to execute that script.

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/20090203/ca51facf/attachment-0001.bin>

From Chris.Barker at noaa.gov  Tue Feb  3 18:25:21 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:25:21 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93738.1233679982@parc.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
	<77379.1233608023@parc.com>
	<F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>
	<93738.1233679982@parc.com>
Message-ID: <49887E01.3090900@noaa.gov>

First:

I've read this thread, I've read the Apple docs (at least one level deep 
-- I really don't "get" this stuff, and I don't have the time to learn 
it all!)

I still don't "get" what LSUIElement is supposed to do, and what 
functionality will change if it's set.

I did try setting it on my system, and saw no difference whatsoever in 
my quick tests with wx.

Could someone (Bill?) summarize what functionally will change if this 
change is applied?

I'm a bit concerned (as expressed by others) that while focusing on one 
use case, that other, very common, usages could be effected.

For that matter, I don't really understand the use case that you're 
trying to address.

Here's my guess -- please correct me:

Some python scripts that are GUI-free are calling some Carbon APIs that 
cause the system to promote them to full-GUI mode, and that then breaks 
things:
  - you get a icon in the doc, which you don't want
  - they are not shut down by the system when logging off/shutting down, 
'cause they don't respond to the appropriate calls.

By the way, that later issues confuses the heck out of me -- why the 
heck would anyone write a system shut down procedure that couldn't 
override a non-responsive application? -- weird. (of course, Windows 
does it too...)

Anyway, it's hard for us to comment on the proposal if we don't' 
understand the issues, and since you are proposing it, the burden is on 
you to educate us -- sorry.

-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  Tue Feb  3 18:33:39 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:33:39 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93756.1233680076@parc.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
	<93756.1233680076@parc.com>
Message-ID: <49887FF3.2060107@noaa.gov>

Bill Janssen wrote:
> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> The fully standalone bundles that py2app creates are very useful, but
>> I definitely see the need for very thin .app bundles as well.
> 
> Interesting idea.  What's the lightest thing that's an app, anyway?

You can run py2app in "Alias" mode ($python setup.py py2app -A), and you 
get a full app bundle that has links to everything it needs, rather than 
actually including it all. They are faster to build, but the main 
advantage is that as the code changes, you don't have to do anything, 
the bundle is referencing the original copy anyway. It still acts as a 
full application.

As an example, I use this to run the Peppy editor (nice editor -- you 
should all take a look at it!). I've got the Alias bundle set up, I put 
it in the dock and just use it like a .app -- click on it to start, drag 
and drop files on it, etc. when I do an "svn up", I get the updated 
version, and don't have to touch a thing.

I'm sure alias bundles have their limitations (aside from the obvious 
one of only working on that machine, with all its python packages), but 
I'm not sure what they are beyond the same limitations of running a 
script directly.

They build faster and more reliably that full py2app bundles, too.

-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  Tue Feb  3 18:49:31 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:49:31 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93806.1233680608@parc.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com>
Message-ID: <498883AB.4030208@noaa.gov>

Bill,

Thanks for making the effort to understand and explain all this. Many of 
us remember the many "why won't this work!" posts to the mailing 
list.... so we just want to be careful.

Some concerns:

> ``LSUIElement (String). If this key is set to '1', Launch Services runs
> the application as an agent application. Agent applications do not
> appear in the Dock or in the Force Quit window.

This is a concern -- what if I do need to "Force Quit" my app? I can 
probably find it with ps, and kill it with kill, but that's only because 
I was a Linux geek before I got a Mac.

Also, if you do want an icon in the dock -- even the default rocket -- 
you would need to do something special to get it, no?

Though: I've tried changing my info.plist and haven't seen any change at 
all -- how do I know if I did it right?

> I'm *only* suggesting this for Python.app --

That's not an ONLY -- that's how most python code is run. IDLE.app is an 
exception -- that's the point here, it sounds like you are trying to 
make things work better for non-gui, background-ish apps, but neglecting 
GUI development.

Sure, once I've got my big app written and bundled up with py2app, I can 
set the info.plist the way I want (and py2app can do "the right thing" 
by default.), but I have a LOT of little wx scripts that I want to work 
when started from the command line.

In short:

I should be able start this script from the command line:

import wx
A = wx.App()
F = wx.Frame(None)
F.Show()

And get a dock icon, and have it show up in Force Quit, and be able to 
do everything else GUI it would usually do.

> The key is that you can always make the process more "heavyweight", but
> you can't go in the other direction.  So Python should start as low as
> possible, and work up as necessary

Which does make sense. As there are really only a few GUI toolkits:

wxPython
TkInter
pyObjC
pyQT

It may be fine to have the GUI code promote the app, but we do need to 
get those devs on board (as Robin apparently already is).

And another option is the "pythonb" option for background apps, 
analogous to the old pythonw

-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  Tue Feb  3 18:51:12 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:51:12 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
Message-ID: <49888410.1070300@noaa.gov>

Ronald Oussoren wrote:
> I'm seriously wondering if having "Python Launcher.app" is a good idea, 
> and if we shouldn't scrap it entirely.

I wonder, too, but if we do keep it, it could have the full-gui 
info.plist anyway -- would that work?

-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  Tue Feb  3 18:53:02 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:53:02 -0800
Subject: [Pythonmac-SIG] wx Window Flashes and Closes Immediately
In-Reply-To: <4987A261.1080909@alldunn.com>
References: <f49ad29d0902012042q68546971n96845e4defb8f1f1@mail.gmail.com>
	<EC8029B9-B92F-4599-B1C2-A4C705F0B607@gmail.com>
	<4987360D.4050100@noaa.gov> <4987A261.1080909@alldunn.com>
Message-ID: <4988847E.8000005@noaa.gov>

Robin Dunn wrote:
>> I thought Robin said that this default was going to be changed, so 
>> that newbies would have this issue less -- what happened to that?
> 
> I didn't think it would be a good idea to change a default like this 
> between two 2.8.x releases, but it's already changed in the 2.9 source 
> tree.

Sounds like the right call -- thanks!

-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  Tue Feb  3 18:54:14 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 09:54:14 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
Message-ID: <498884C6.9090900@noaa.gov>

Henning Hraban Ramm wrote:
> Most of *my* wxPython-based (actually dabo-based) tools don't even need 
> to be an app bundle - doubleclicking some .py file is mostly enough.


Check out "py2app -A". It's perfect for this kind of use.

-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 janssen at parc.com  Tue Feb  3 18:55:56 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 09:55:56 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <6BEEF715-BFC6-4A4C-9EDE-84355C028B5C@mac.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
	<93756.1233680076@parc.com>
	<6BEEF715-BFC6-4A4C-9EDE-84355C028B5C@mac.com>
Message-ID: <95524.1233683756@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> 
> On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
> >
> >> I'm seriously wondering if having "Python Launcher.app" is a good
> >> idea, and if we shouldn't scrap it entirely. If building full app
> >> bundles using py2app is too much of a burden we could look into
> >> providing an easier and more lightweight way to build such bundles.
> >> The fully standalone bundles that py2app creates are very useful, but
> >> I definitely see the need for very thin .app bundles as well.
> >
> > Interesting idea.  What's the lightest thing that's an app, anyway?
> >
> 
> AFAIK an executable + Info.plist + icon file (plus the right directory
> structure). The executable can be shell-script on Leopard, but a
> simple executable would IMHO be better.  One way to structure such an
> executable is to read the name of the actual script to execute from
> the Info.plist (using a custom key) and then use the standard Python
> C- 
> API to execute that script.

So you'd have a little custom launcher that would read that key and use
the Python C API -- sort of the way that Java apps use the
JavaApplicationStub.  Doesn't actually have to be a C program, you know;
it could be a shell script:

  #!/usr/bin/python
  import plistlib, os
  script = os.path.normpath(plistlib.readPlist('../Info.plist')['ApplicationPythonScript'])
  os.execv(['/usr/bin/python', script])

I didn't test that!

Bill

From janssen at parc.com  Tue Feb  3 19:00:49 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 10:00:49 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <49887E01.3090900@noaa.gov>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
	<77379.1233608023@parc.com>
	<F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>
	<93738.1233679982@parc.com> <49887E01.3090900@noaa.gov>
Message-ID: <95579.1233684049@parc.com>

Chris, I'm a bit confused, too.

> Could someone (Bill?) summarize what functionally will change if this
> change is applied?

Basically, if you're running /usr/bin/python or Python.app directly, you
still won't get a dock icon even if you're using appscript.  The app is
marked as an agent application -- still trying to figure out just what
that means.

> Some python scripts that are GUI-free are calling some Carbon APIs
> that cause the system to promote them to full-GUI mode, and that then
> breaks things:
>  - you get a icon in the doc, which you don't want
>  - they are not shut down by the system when logging off/shutting
> down, 'cause they don't respond to the appropriate calls.

Yep, that's what seems to be happening.

> By the way, that later issues confuses the heck out of me -- why the
> heck would anyone write a system shut down procedure that couldn't
> override a non-responsive application? -- weird. (of course, Windows
> does it too...)

Excellent point.  I think what happens is that the system thinks Python
should be responding to it, and when it doesn't (because it's been
improperly promoted), it feels it might have timed out, and to avoid
losing your data, cancels the logout.  I assume there's some magic key
combo you could press while logging out to override that protection; I
just don't know what it is.

Bill

From janssen at parc.com  Tue Feb  3 19:14:23 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 10:14:23 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <498883AB.4030208@noaa.gov>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com> <498883AB.4030208@noaa.gov>
Message-ID: <95986.1233684863@parc.com>

Christopher Barker <Chris.Barker at noaa.gov> wrote:

> This is a concern -- what if I do need to "Force Quit" my app? I can
> probably find it with ps, and kill it with kill, but that's only
> because I was a Linux geek before I got a Mac.

Then give your app its own Info.plist.  There are zillions of processes
running on your Mac that don't appear in the "Force Quit" window --
that's what Activity Monitor is for.

> Also, if you do want an icon in the dock -- even the default rocket -- 
> you would need to do something special to get it, no?

Yes -- use a different Info.plist.

> Though: I've tried changing my info.plist and haven't seen any change
> at all -- how do I know if I did it right?

I'm tempted to say: if you don't know whether or not you've done it
right, don't try doing it at all.

But in the spirit of education, here's what I've got in my Python.app's
Info.plist:

	<key>LSUIElement</key>
	<true/>

> > The key is that you can always make the process more "heavyweight", but
> > you can't go in the other direction.  So Python should start as low as
> > possible, and work up as necessary
> 
> Which does make sense.

Thanks!

> As there are really only a few GUI toolkits:
> 
> wxPython
> TkInter
> pyObjC
> pyQT
> 
> It may be fine to have the GUI code promote the app, but we do need to
> get those devs on board (as Robin apparently already is).

Sure.  TkInter is part of Python, so any patch should cover that as
well.  PyObjC programs can make the call directly, if they wish to, but
most PyObjC programs with windows are probably full-fledged apps,
anyway.  Don't know much about pyQt, or pyGTK.

I also don't think the GUI toolkit should promote willy-nilly -- it
should probably provide a call which the user program can make to
promote.

> And another option is the "pythonb" option for background apps,
> analogous to the old pythonw

Or PythonBackground.app, which would also be a way to slice this.

Bill

From ronaldoussoren at mac.com  Tue Feb  3 19:24:03 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Feb 2009 19:24:03 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <95524.1233683756@parc.com>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<4534084A-C9BB-4A84-99DC-0939243A0C10@mac.com>
	<93756.1233680076@parc.com>
	<6BEEF715-BFC6-4A4C-9EDE-84355C028B5C@mac.com>
	<95524.1233683756@parc.com>
Message-ID: <B64F999C-0747-4393-A0C9-A5BFDA0821EA@mac.com>


On 3 Feb, 2009, at 18:55, Bill Janssen wrote:

> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>>
>> On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
>>>
>>>> I'm seriously wondering if having "Python Launcher.app" is a good
>>>> idea, and if we shouldn't scrap it entirely. If building full app
>>>> bundles using py2app is too much of a burden we could look into
>>>> providing an easier and more lightweight way to build such bundles.
>>>> The fully standalone bundles that py2app creates are very useful,  
>>>> but
>>>> I definitely see the need for very thin .app bundles as well.
>>>
>>> Interesting idea.  What's the lightest thing that's an app, anyway?
>>>
>>
>> AFAIK an executable + Info.plist + icon file (plus the right  
>> directory
>> structure). The executable can be shell-script on Leopard, but a
>> simple executable would IMHO be better.  One way to structure such an
>> executable is to read the name of the actual script to execute from
>> the Info.plist (using a custom key) and then use the standard Python
>> C-
>> API to execute that script.
>
> So you'd have a little custom launcher that would read that key and  
> use
> the Python C API -- sort of the way that Java apps use the
> JavaApplicationStub.  Doesn't actually have to be a C program, you  
> know;
> it could be a shell script:
>
>  #!/usr/bin/python
>  import plistlib, os
>  script = os.path.normpath(plistlib.readPlist('../Info.plist') 
> ['ApplicationPythonScript'])
>  os.execv(['/usr/bin/python', script])
>
> I didn't test that!

Not quite, you must ensure that the C-level argv[0] points to a  
location inside the app bundle, otherwise the system won't know you're  
supposed to be an executable. Getting that right is possible (just  
copy the python executable into the bundle as well), but just writing  
a small stub executable is not too hard and avoids issues like <http://bugs.python.org/issue5143 
 >.

Ronald
>
>
> Bill

-------------- 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/20090203/e975574a/attachment.bin>

From hraban at fiee.net  Tue Feb  3 21:54:56 2009
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Tue, 3 Feb 2009 21:54:56 +0100
Subject: [Pythonmac-SIG] py2app (was: Should Python.app be an
	LSUIElement = 1 app?)
In-Reply-To: <498884C6.9090900@noaa.gov>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<498884C6.9090900@noaa.gov>
Message-ID: <14359DB7-48F5-408B-BBF3-6EE062770D1A@fiee.net>

Am 2009-02-03 um 18:54 schrieb Christopher Barker:

>> Most of *my* wxPython-based (actually dabo-based) tools don't even  
>> need to be an app bundle - doubleclicking some .py file is mostly  
>> enough.
>
> Check out "py2app -A". It's perfect for this kind of use.

Hm, what do you mean? Should there be a standalone py2app script  
anywhere?
I know only "python setup.py py2app", and therefore I'd need to write  
a setup.py



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





From brianz at gmail.com  Tue Feb  3 08:00:23 2009
From: brianz at gmail.com (Brian Zambrano)
Date: Mon, 2 Feb 2009 23:00:23 -0800
Subject: [Pythonmac-SIG] py2app with matplotlib
Message-ID: <5db256250902022300ref736e5m7516e53ec0c064d1@mail.gmail.com>

I've searched around and found some mentions of problems when building apps
with matplotlib, but didn't see any definitive solutions.

I'm trying to build a simple using matplotlib, numpy and wx.  My setup.py
looks like this:

from setuptools import setup

APP = ['plot_in_wx_test.py']
DATA_FILES = ['IMV_0.log']
OPTIONS = {
    'argv_emulation': True,
    'packages': ['matplotlib', 'numpy']
}

setup(
    app=APP,
    data_files=DATA_FILES,
    options={'py2app': OPTIONS},
    setup_requires=['py2app'],
)

# EOF

When I do:

brianz at omaha$ ls -F
dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/
config@            matplotlib/        site-packages.zip
lib-dynload/       numpy/             site.py@

Yet, when I try to run
./dist/wx_mpl_dynamic_graph.app/Contents/MacOS/wx_mpl_dynamic_graph I get an
import error....the application appears to know nothing about any type of
matplotlib:

  File
"...../dist/wx_mpl_dynamic_graph.app/Contents/Resources/wx_mpl_dynamic_graph.py",
line 31, in <module>
    import matplotlib
ImportError: No module named matplotlib

Am I doing something wrong or is this a known issue?

BZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090202/7299de84/attachment-0001.htm>

From Chris.Barker at noaa.gov  Wed Feb  4 01:05:19 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 16:05:19 -0800
Subject: [Pythonmac-SIG] py2app
In-Reply-To: <14359DB7-48F5-408B-BBF3-6EE062770D1A@fiee.net>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org> <49877D30.8010004@noaa.gov>
	<81404.1233616833@parc.com> <49878B05.5010908@noaa.gov>
	<83446.1233620977@parc.com> <4987A507.9040103@alldunn.com>
	<86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<498884C6.9090900@noaa.gov>
	<14359DB7-48F5-408B-BBF3-6EE062770D1A@fiee.net>
Message-ID: <4988DBBF.5070405@noaa.gov>

Henning Hraban Ramm wrote:
> Hm, what do you mean? Should there be a standalone py2app script anywhere?

nope.

> I know only "python setup.py py2app",

right, so you add the -A:

python setup.py py2app -A

 > and therefore I'd need to write a
> setup.py

which is trivial for the simple case, and you can use the py2applet 
script to build it for you.

$ py2applet

usage: py2applet --make-setup [options...] script.py [data files...]
    or: py2applet [options...] script.py [data files...]
    or: py2applet --help


but yes, if you just want to run a really quickie little GUI script, you 
want to just run it! Which is why we all want that to still work.

The alias option works great for a small-to-huge GUI app under 
development, though -- once you've built the applet, you can just keep 
using it as you change your code, and it give you drag and drop and all 
that.

-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 kw at codebykevin.com  Wed Feb  4 00:42:13 2009
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 03 Feb 2009 18:42:13 -0500
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93806.1233680608@parc.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com>
Message-ID: <4988D655.5010202@codebykevin.com>

Bill Janssen wrote:
> has <hengist.podd at virgin.net> wrote:
> 
>> Annoying, but tweaking
>> the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
>> solution, it's a kludge - one that will take us back to the bad old
>> days where some scripts automatically fail when run with 'python'.
> 
> *Right now*, some scripts fail when run with "python".  My scripts :-).
> 
> Look, setting LSUIElement still allows access to the WM -- that's what
> it's for:
> 
> ``LSUIElement (String). If this key is set to '1', Launch Services runs
> the application as an agent application. Agent applications do not
> appear in the Dock or in the Force Quit window. Although they typically
> run as background applications, they can come to the foreground to
> present a user interface if desired. A click on a window belonging to an
> agent application brings that application forward to handle events.''
> 
> I'm *only* suggesting this for Python.app -- other Python-based apps,
> like IDLE.app, that desire a dock icon can still have a different
> Info.plist.
> 
> For that matter, even if we set LSBackgroundOnly, you'd still have
> access to the WM -- my appscript-based "while True" loop runs fine when
> I set this flag.
> 
> The key is that you can always make the process more "heavyweight", but
> you can't go in the other direction.  So Python should start as low as
> possible, and work up as necessary.
> 
> Bill

I've been following this proposed change with some interest. My gut is 
telling me a strong "no" on it.

My development is of GUI apps, and I like being able to double-click on 
a Python script and have it do the Right Thing--that is, launch as a 
foreground GUI process in Tkinter. Having to run py2app to test my apps 
would be a rather large pain. Having to remember to run "pythonw" 
instead of "python" if I'm testing in Terminal would be nearly as much 
pain. (PythonLauncher was broken in 2.5.x, at least for a couple of 
iterations, and I'm pleased it's working again in 2.6.)

Bill, the behavior that you experiencing is the expected behavior of 
Python, albeit not what you want in this instance. Rather than re-doing 
the long-standing infractucture of Python on the Mac, wouldn't it be 
better to find the code that is causing the undesired "rocket launch" 
and fix it, or at least work around it? Woudn't a non-framework, 
Unix-style build of Python avoid these issues altogether?

--Kevin


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

From kw at codebykevin.com  Wed Feb  4 01:08:07 2009
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 03 Feb 2009 19:08:07 -0500
Subject: [Pythonmac-SIG] [Fwd: Re: Should Python.app be an LSUIElement = 1
 app?]
Message-ID: <4988DC67.4040704@codebykevin.com>

Looks like this died in cyberspace...
-------------- next part --------------
An embedded message was scrubbed...
From: Kevin Walzer <kw at codebykevin.com>
Subject: Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Date: Tue, 03 Feb 2009 18:42:13 -0500
Size: 3259
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090203/79757cb9/attachment.eml>

From Chris.Barker at noaa.gov  Wed Feb  4 01:14:52 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Feb 2009 16:14:52 -0800
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4988D655.5010202@codebykevin.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com> <4988D655.5010202@codebykevin.com>
Message-ID: <4988DDFC.1070006@noaa.gov>

Kevin Walzer wrote:
> My development is of GUI apps, and I like being able to double-click on 
> a Python script and have it do the Right Thing--that is, launch as a 
> foreground GUI process in Tkinter.

I think it's clear that lot's of us want that. the question is, will the 
proposal break that?

One option is that the GUI toolkits run the code to promote themselves 
to a full GUI app. In which case, I think you're above scenario would 
work. OF course, ALL the gui toolkits would have to add that code, but 
if they did, would that meet your needs?

-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 janssen at parc.com  Wed Feb  4 02:27:27 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 17:27:27 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4988D655.5010202@codebykevin.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com> <4988D655.5010202@codebykevin.com>
Message-ID: <3422.1233710847@parc.com>

Kevin Walzer <kw at codebykevin.com> wrote:

> Bill, the behavior that you experiencing is the expected behavior of 
> Python, albeit not what you want in this instance. Rather than re-doing 
> the long-standing infractucture of Python on the Mac, wouldn't it be 
> better to find the code that is causing the undesired "rocket launch" 
> and fix it, or at least work around it? Woudn't a non-framework, 
> Unix-style build of Python avoid these issues altogether?

It would, and that's actually the "long-standing infrastructure of
Python on the Mac" that you refer to.  The Python.app formulation is
recent, and not yet well-enough debugged.

Try setting LSUIElement in your Python.app's Info.plist, and report back
with what's broken.  I think you'll find double-clicking on UI apps
works just fine.

Though I also think that launching by double-clicking on .py files is a
mistaken binding.  It should probably bring up an editor.

Bill

From janssen at parc.com  Wed Feb  4 02:35:52 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 3 Feb 2009 17:35:52 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <3422.1233710847@parc.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com> <4988D655.5010202@codebykevin.com>
	<3422.1233710847@parc.com>
Message-ID: <3854.1233711352@parc.com>

Bill Janssen <janssen at parc.com> wrote:

> It would, and that's actually the "long-standing infrastructure of
> Python on the Mac" that you refer to.  The Python.app formulation is
> recent, and not yet well-enough debugged.

Though, I should hasten to say, I think removing the distinction between
python and pythonw was a decided improvement.

Bill

From ronaldoussoren at mac.com  Wed Feb  4 07:49:56 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 07:49:56 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <93649.1233679741@parc.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
Message-ID: <20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>


On 3 Feb, 2009, at 17:49, Bill Janssen wrote:

> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>> if I understand the
>> LSUIElement document correctly the setting you propose would make it
>> impossible to use "python sometkscript.py" to run a simple GUI  
>> script.
>
> Then you misunderstand either LSUIElement, or the discussion so far.
> What we'd like to do is to retain that capability.

I've tested the LSUIElement key with a GUI script, and based on that  
I'm opposed to including that key in Python.app. You can always wrap  
your scripts in an app bundle that does have the key set, or  
investigate how to avoid getting the rocket icon in the dock when you  
use appscript, as Has suggested.

LSUIElement=1 completely surpresses the dock icon and menu bar for an  
application, although you can get those back by calling an API. This  
would be a support nightmare for python.app, any (OSX) newby that runs  
a Tkinter script from a tutorial ends up with a non-functional  
application.  Furthermore cross-platform scripts would have to call  
the "upgrade-API" to ensure they have a menu, making OSX different  
from Linux and Windows.

Both could be worked around by including a call to the "upgrade-API"  
in the startup code for GUI toolkits (Tkinter, WxWidget, QT, ...), but  
that would mean you can no longer create agent applications using  
those toolkits. An agent application is supposed to be a mostly  
faceless background application that can pop-up a window when it needs  
to. I guess Growl would be a good example of such functionality,  
although I haven't checked if they use the LSUIElement key.

Ronald

>
>
> Please read the Apple document I referenced earlier to get an idea of
> what the three different classes of application are.  In any case, you
> can always "promote" an app to a heavier-weight presence; what Apple
> doesn't give us an interface for is to "demote" the app if it's been
> promoted by accident.
>
> Bill

-------------- 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/20090204/0ca8076c/attachment.bin>

From brianz at gmail.com  Wed Feb  4 08:20:07 2009
From: brianz at gmail.com (Brian Zambrano)
Date: Tue, 3 Feb 2009 23:20:07 -0800
Subject: [Pythonmac-SIG] py2app with matplotlib
In-Reply-To: <5db256250902022300ref736e5m7516e53ec0c064d1@mail.gmail.com>
References: <5db256250902022300ref736e5m7516e53ec0c064d1@mail.gmail.com>
Message-ID: <5db256250902032320t355a0ab3j9a3301a65b8d1d5a@mail.gmail.com>

On Mon, Feb 2, 2009 at 11:00 PM, Brian Zambrano <brianz at gmail.com> wrote:

> When I do:
>
> brianz at omaha$ ls -F
> dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/
> config@            matplotlib/        site-packages.zip
> lib-dynload/       numpy/             site.py@
>
> Yet, when I try to run
> ./dist/wx_mpl_dynamic_graph.app/Contents/MacOS/wx_mpl_dynamic_graph I get an
> import error....the application appears to know nothing about any type of
> matplotlib:
>
>   File
> "...../dist/wx_mpl_dynamic_graph.app/Contents/Resources/wx_mpl_dynamic_graph.py",
> line 31, in <module>
>     import matplotlib
> ImportError: No module named matplotlib
>

After some hunting and digging I solved this.  After upgrading Python 2.5.1
which comes in OS X 10.5 to Python 2.5.4, all is well.

I found this out in a roundabout way....first I got it working after
realizing the path was off when the App fired up.  The libraries were ending
up in

dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/

which wasn't in sys.path.  What *was* in sys.path was:

dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/site-packages

After a little hackery I got it working.  Then I realized that Python wasn't
being included in the build so upgraded to 2.5.4 (which wasn't as simple as
I hoped).  After that, the build worked no problem.  Hopefully this will be
useful to someone else.

BZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090203/f1cfae0a/attachment.htm>

From hraban at fiee.net  Wed Feb  4 09:56:48 2009
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Wed, 4 Feb 2009 09:56:48 +0100
Subject: [Pythonmac-SIG] py2app
In-Reply-To: <4988DBBF.5070405@noaa.gov>
References: <73365.1233593908@parc.com>
	<nad-AC5408.13051502022009@news.gmane.org>
	<49877D30.8010004@noaa.gov> <81404.1233616833@parc.com>
	<49878B05.5010908@noaa.gov> <83446.1233620977@parc.com>
	<4987A507.9040103@alldunn.com> <86233.1233629245@parc.com>
	<1CDF1D3E-EE29-4E98-8BF7-3A5BCF5F9E24@fiee.net>
	<498884C6.9090900@noaa.gov>
	<14359DB7-48F5-408B-BBF3-6EE062770D1A@fiee.net>
	<4988DBBF.5070405@noaa.gov>
Message-ID: <B954AAF4-0FE2-45DA-B6DE-354F2F8FF2EC@fiee.net>

Am 2009-02-04 um 01:05 schrieb Christopher Barker:

>> Hm, what do you mean? Should there be a standalone py2app script  
>> anywhere?
>
> nope.
>
>> I know only "python setup.py py2app",
>
> right, so you add the -A:
>
> python setup.py py2app -A
>
> > and therefore I'd need to write a
>> setup.py
>
> which is trivial for the simple case, and you can use the py2applet  
> script to build it for you.
>
> $ py2applet
>
> usage: py2applet --make-setup [options...] script.py [data files...]
>   or: py2applet [options...] script.py [data files...]
>   or: py2applet --help
>
>
> but yes, if you just want to run a really quickie little GUI script,  
> you want to just run it! Which is why we all want that to still work.
>
> The alias option works great for a small-to-huge GUI app under  
> development, though -- once you've built the applet, you can just  
> keep using it as you change your code, and it give you drag and drop  
> and all that.

Thank you for the clarification.

It's only that I use a folder full of small tools, partly with GUI,  
most of them access the same packages, and I don't like to mess this  
up with lots of setup.py or more subfolders.

I package only those few tools that my colleagues can use standalone  
(I keep those on a server share, so I can easily update them for all  
and nobody must fill their diskspace with redundant code of bloated  
python apps).

No need to argue...


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





From janssen at parc.com  Wed Feb  4 18:50:48 2009
From: janssen at parc.com (Bill Janssen)
Date: Wed, 4 Feb 2009 09:50:48 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
Message-ID: <12522.1233769848@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> LSUIElement=1 completely surpresses the dock icon and menu bar for an
> application, although you can get those back by calling an API. This
> would be a support nightmare for python.app, any (OSX) newby that runs
> a Tkinter script from a tutorial ends up with a non-functional
> application.

Whether we need to also upgrade the tutorials strikes me as a minor
matter.

> Furthermore cross-platform scripts would have to call
> the "upgrade-API" to ensure they have a menu, making OSX different
> from Linux and Windows.

No, as you then point out...

> Both could be worked around by including a call to the "upgrade-API"
> in the startup code for GUI toolkits (Tkinter, WxWidget, QT, ...), but
> that would mean you can no longer create agent applications using
> those toolkits.

Yeah, we'd want to a call in the toolkit to make to enable that, which
modifies the level that the automatic upgrade upgrades to.

> An agent application is supposed to be a mostly
> faceless background application that can pop-up a window when it needs
> to. I guess Growl would be a good example of such functionality,
> although I haven't checked if they use the LSUIElement key.

Bill

From ronaldoussoren at mac.com  Wed Feb  4 21:38:55 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 21:38:55 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <12522.1233769848@parc.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
Message-ID: <C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>


On 4 Feb, 2009, at 18:50, Bill Janssen wrote:

> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>> LSUIElement=1 completely surpresses the dock icon and menu bar for an
>> application, although you can get those back by calling an API. This
>> would be a support nightmare for python.app, any (OSX) newby that  
>> runs
>> a Tkinter script from a tutorial ends up with a non-functional
>> application.
>
> Whether we need to also upgrade the tutorials strikes me as a minor
> matter.

You'd have to modify every tutorial out there, including books. That's  
not
really feaseable.

The right ways to fix the issue you're running into with appscript are

1) Wrap your script into an .app bundle that includes the LSUIElement  
setting (because appeartly you are writing an application that is an  
agent-style application)

2) Research why appscript causes the icon to appear on the dock. As  
has noted it should be possible to avoid that because the  
ScriptingBridge framework doesn't have this problem.

The second option would be the most useful for the community, but is  
way harder than the first option.

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/20090204/db110e7a/attachment.bin>

From hengist.podd at virgin.net  Wed Feb  4 21:44:32 2009
From: hengist.podd at virgin.net (has)
Date: Wed, 4 Feb 2009 20:44:32 +0000
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <mailman.50.1233745212.21918.pythonmac-sig@python.org>
References: <mailman.50.1233745212.21918.pythonmac-sig@python.org>
Message-ID: <2126A4A7-B668-4E79-8DEE-6502AF50463B@virgin.net>

Ronald Oussoren wrote:

> I've tested the LSUIElement key with a GUI script, and based on that  
> I'm opposed to including that key in Python.app. You can always wrap  
> your scripts in an app bundle that does have the key set, or  
> investigate how to avoid getting the rocket icon in the dock when  
> you use appscript, as Has suggested. [...]

Agreed. Today's MacPython is, or should be, a superset of standard  
*nix Python. OS X is *nix at the shell level, and tools that work on  
other *nixes ought to work the same on OS X, otherwise you end up in a  
situation where users have to maintain two separate Python  
installations for compatibility. Users won't like that; neither, I  
suspect, would Apple.

Bill's problem is with appscript; that's where the fix should be as  
well. I don't have time to work on it, but y'all are welcome to grab  
the latest trunk and hack on it.

Regards,

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From ronaldoussoren at mac.com  Wed Feb  4 23:00:09 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 23:00:09 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <95579.1233684049@parc.com>
References: <73365.1233593908@parc.com> <498736CF.2010905@noaa.gov>
	<75297.1233599229@parc.com> <49874050.7090309@noaa.gov>
	<77379.1233608023@parc.com>
	<F33588F1-6AF3-4808-8C98-CBE42D0AE799@mac.com>
	<93738.1233679982@parc.com> <49887E01.3090900@noaa.gov>
	<95579.1233684049@parc.com>
Message-ID: <901CC024-0F9A-4305-B3C3-0A1DC2518FC2@mac.com>


On 3 Feb, 2009, at 19:00, Bill Janssen wrote:

> Chris, I'm a bit confused, too.
>
>> Could someone (Bill?) summarize what functionally will change if this
>> change is applied?
>
> Basically, if you're running /usr/bin/python or Python.app directly,  
> you
> still won't get a dock icon even if you're using appscript.  The app  
> is
> marked as an agent application -- still trying to figure out just what
> that means.

That means you won't get a menu bar either.  "agent application" seems  
to mean an application that is usually completely hidden but needs to  
pop up GUI items (such as windows) sometimes. Agent applications don't  
have a dock item, and don't have a menu bar either.

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/20090204/f2c7c533/attachment.bin>

From ronaldoussoren at mac.com  Wed Feb  4 23:03:08 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 23:03:08 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <95986.1233684863@parc.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com>
	<498883AB.4030208@noaa.gov> <95986.1233684863@parc.com>
Message-ID: <9D430F06-711B-4017-81F9-74F153B47A3F@mac.com>


On 3 Feb, 2009, at 19:14, Bill Janssen wrote:
>
> But in the spirit of education, here's what I've got in my  
> Python.app's
> Info.plist:
>
> 	<key>LSUIElement</key>
> 	<true/>

That's the wrong definition, it should be:

    <key>LSUIElement</key>
    <string>1</string>

See <http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-108256 
 >, or /System/Library/CoreServices/Dock.app/Contents/Info.plist.

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/20090204/eb0ab871/attachment-0001.bin>

From ronaldoussoren at mac.com  Wed Feb  4 23:11:08 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 23:11:08 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4988DDFC.1070006@noaa.gov>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com>
	<4988D655.5010202@codebykevin.com> <4988DDFC.1070006@noaa.gov>
Message-ID: <8D5BD9A7-B7EB-4633-9F55-CA5660884599@mac.com>


On 4 Feb, 2009, at 1:14, Christopher Barker wrote:

> Kevin Walzer wrote:
>> My development is of GUI apps, and I like being able to double- 
>> click on a Python script and have it do the Right Thing--that is,  
>> launch as a foreground GUI process in Tkinter.
>
> I think it's clear that lot's of us want that. the question is, will  
> the proposal break that?
>
> One option is that the GUI toolkits run the code to promote  
> themselves to a full GUI app. In which case, I think you're above  
> scenario would work. OF course, ALL the gui toolkits would have to  
> add that code, but if they did, would that meet your needs?

If GUI toolkits automaticly promote themselves to full GUI apps you  
can no longer create an agent-style application in Python. Or at least  
not without introducing another API that disables the promotion, said  
API would be non-standard and therefore not easily findable.

I haven't read the recent history of this list to find the thread that  
triggered this thread, but from the bits I have read it seems that  
there is one major reason for wanting this feature: when you use  
appscript from a non-gui script you might end up with a rocket icon in  
your dock because appscript calls an API that promotes the application  
to GUI status.  Adding the LSUIElement key to the Info.plist file is  
basically a workaround for an unwanted (and probably avoidable)  
feature caused by some Carbon call(s) in the appscript  
implementation.  The way to fix that issue is not to add LSUIElement  
to the Info.plist, but to look for a way to avoid calling the API(s)  
that cause the promotion to full GUI status.

I will look at appscript, but not before Pycon.

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/20090204/176c36a0/attachment.bin>

From ronaldoussoren at mac.com  Wed Feb  4 23:13:11 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Feb 2009 23:13:11 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <3422.1233710847@parc.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com>
	<4988D655.5010202@codebykevin.com> <3422.1233710847@parc.com>
Message-ID: <433D861C-A4E5-4780-BF5E-1DB6CF1FC17E@mac.com>


On 4 Feb, 2009, at 2:27, Bill Janssen wrote:

> Kevin Walzer <kw at codebykevin.com> wrote:
>
>> Bill, the behavior that you experiencing is the expected behavior of
>> Python, albeit not what you want in this instance. Rather than re- 
>> doing
>> the long-standing infractucture of Python on the Mac, wouldn't it be
>> better to find the code that is causing the undesired "rocket launch"
>> and fix it, or at least work around it? Woudn't a non-framework,
>> Unix-style build of Python avoid these issues altogether?
>
> It would, and that's actually the "long-standing infrastructure of
> Python on the Mac" that you refer to.  The Python.app formulation is
> recent, and not yet well-enough debugged.

The Python.app formulation is about as old as OSX, that count as long- 
standing in my book.

>
> Try setting LSUIElement in your Python.app's Info.plist, and report  
> back
> with what's broken.  I think you'll find double-clicking on UI apps
> works just fine.

Double-clicking GUI script probably won't work just fine, the dock  
icon and menu bar will be surpressed by setting the LSUIElement key.

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/20090204/a4c28eaf/attachment.bin>

From listmail at gearyweb.com  Wed Feb  4 22:48:34 2009
From: listmail at gearyweb.com (michael geary)
Date: Wed, 4 Feb 2009 14:48:34 -0700
Subject: [Pythonmac-SIG] help! coregraphics+python+webserver suddenly fails
Message-ID: <FB2F4F4B-67B0-4DC5-AAA2-6461B9888920@gearyweb.com>

Hi Folks,

i have very little experience with anything relating to cocoa, and not  
much more with quartz, but i'm an experienced web app developer, and  
have used python quite a bit. This list is the closest thing i can  
find to a forum where i can discuss this issue.

I have a script that i've been using for a long time to create jpeg  
previews of PDF documents, and it recently started failing. Here is  
the essence of the script:

-----------------
pdfData =  
CGPDFDocumentCreateWithProvider(CGDataProviderCreateWithFilename  
(pdfPath))

originalRect = pdfData.getMediaBox(page)

res = float(res)

origWidth, origHeight =  
(originalRect.size.width,originalRect.size.height)
width, height = (originalRect.size.width,originalRect.size.height)

newRect = CGRectMake(0,0,width*res/72.0,height*res/72.0)

## set the color space (rgb):
cs = CGColorSpaceCreateWithName(kCGColorSpaceUserRGB)

## set the context (whatever that is). Background color is hardcoded  
to white for now:
ctx = CGBitmapContextCreateWithColor(int(newRect.size.width),  
int(newRect.size.height),cs, (1, 1, 1, 1))

## draw the image
ctx.drawPDFDocument(newRect, pdfData, page)	

## write out the jpeg
ctx.writeToFile(jpegPath, kCGImageFormatJPEG)

----------------

The problem i'm now suddenly getting (i'm on 10.5.6) is on the  
drawPDFDocument() call. When i hit that, the following gets logged to  
the system log:

/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python[402]: ATSClient: can't make  
connection to ATSServer. bootstrap_look_up status = 268435459

/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python[402]: ATSClient: can't re-connect  
with ATSServer   status = -3182

Python[402]: ATSFontActivateFromMemory failed: error -3182.

Help! Can anyone offer any insights?

thanks,

michael geary

From janssen at parc.com  Wed Feb  4 23:26:06 2009
From: janssen at parc.com (Bill Janssen)
Date: Wed, 4 Feb 2009 14:26:06 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
	<C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
Message-ID: <16584.1233786366@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> > Whether we need to also upgrade the tutorials strikes me as a minor
> > matter.
> 
> You'd have to modify every tutorial out there, including books. That's  
> not
> really feaseable.

Python changes.  Tutorials need to keep changing.

> The right ways to fix the issue you're running into with appscript are
> 
> 1) Wrap your script into an .app bundle that includes the LSUIElement  
> setting (because appeartly you are writing an application that is an  
> agent-style application)
> 
> 2) Research why appscript causes the icon to appear on the dock. As  
> has noted it should be possible to avoid that because the  
> ScriptingBridge framework doesn't have this problem.
> 
> The second option would be the most useful for the community, but is  
> way harder than the first option.

Yes, both of those are good ideas.  But it's not just appscript; I'm
doing something else in a different program (that doesn't use appscript)
that also causes the rocket-in-the-dock problem.  This one is
particularly irritating, because it's a real daemon, and can't always
get through to the dock.

Bill

From janssen at parc.com  Wed Feb  4 23:27:37 2009
From: janssen at parc.com (Bill Janssen)
Date: Wed, 4 Feb 2009 14:27:37 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <9D430F06-711B-4017-81F9-74F153B47A3F@mac.com>
References: <mailman.39895.1233625709.3486.pythonmac-sig@python.org>
	<146A7207-6375-4ED1-9594-FCEAC4B53AE1@virgin.net>
	<93806.1233680608@parc.com> <498883AB.4030208@noaa.gov>
	<95986.1233684863@parc.com>
	<9D430F06-711B-4017-81F9-74F153B47A3F@mac.com>
Message-ID: <16597.1233786457@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> On 3 Feb, 2009, at 19:14, Bill Janssen wrote:
> >
> > But in the spirit of education, here's what I've got in my  
> > Python.app's
> > Info.plist:
> >
> > 	<key>LSUIElement</key>
> > 	<true/>
> 
> That's the wrong definition, it should be:
> 
>     <key>LSUIElement</key>
>     <string>1</string>

Thanks for the correction, Ronald.  But it seems to do the trick, too.

Bill

From ronaldoussoren at mac.com  Thu Feb  5 08:14:58 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 05 Feb 2009 08:14:58 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <16584.1233786366@parc.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
	<C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
	<16584.1233786366@parc.com>
Message-ID: <2FC01A3C-640C-4DAB-8521-D51D660E738C@mac.com>


On 4 Feb, 2009, at 23:26, Bill Janssen wrote:
>
>
>> The right ways to fix the issue you're running into with appscript  
>> are
>>
>> 1) Wrap your script into an .app bundle that includes the LSUIElement
>> setting (because appeartly you are writing an application that is an
>> agent-style application)
>>
>> 2) Research why appscript causes the icon to appear on the dock. As
>> has noted it should be possible to avoid that because the
>> ScriptingBridge framework doesn't have this problem.
>>
>> The second option would be the most useful for the community, but is
>> way harder than the first option.
>
> Yes, both of those are good ideas.  But it's not just appscript; I'm
> doing something else in a different program (that doesn't use  
> appscript)
> that also causes the rocket-in-the-dock problem.  This one is
> particularly irritating, because it's a real daemon, and can't always
> get through to the dock.

Can you  reproduce the issue in the second problem with a simple  
script? If so, please file a bug in the python bugtracker and assign  
it to me.

The dock icon should mean you're calling an API that requires access  
to the window server. Does the daemon program work when you start it  
without begin logged on to the console (that is, log in using an SSH  
session without being logged on on the console)? If that doesn't work,  
it  shouldn't work either with and without the LSUIElement key.

Ronald
>
>
> Bill

-------------- 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/20090205/f8257138/attachment.bin>

From janssen at parc.com  Thu Feb  5 17:04:36 2009
From: janssen at parc.com (Bill Janssen)
Date: Thu, 5 Feb 2009 08:04:36 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <2FC01A3C-640C-4DAB-8521-D51D660E738C@mac.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
	<C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
	<16584.1233786366@parc.com>
	<2FC01A3C-640C-4DAB-8521-D51D660E738C@mac.com>
Message-ID: <63075.1233849876@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> Can you  reproduce the issue in the second problem with a simple
> script? If so, please file a bug in the python bugtracker and assign
> it to me.

If I could, I'd be halfway to fixing it -- but thanks!

> The dock icon should mean you're calling an API that requires access
> to the window server. Does the daemon program work when you start it
> without begin logged on to the console (that is, log in using an SSH
> session without being logged on on the console)? If that doesn't work,
> it  shouldn't work either with and without the LSUIElement key.

Right.  But it also means that there are more things than appscript
which can cause this.

Bill

From ronaldoussoren at mac.com  Thu Feb  5 17:12:21 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 05 Feb 2009 17:12:21 +0100
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <63075.1233849876@parc.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
	<C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
	<16584.1233786366@parc.com>
	<2FC01A3C-640C-4DAB-8521-D51D660E738C@mac.com>
	<63075.1233849876@parc.com>
Message-ID: <4AE8366C-A45E-48F9-9C95-4824DC2C4CCF@mac.com>


On 5 Feb, 2009, at 17:04, Bill Janssen wrote:

> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
>> The dock icon should mean you're calling an API that requires access
>> to the window server. Does the daemon program work when you start it
>> without begin logged on to the console (that is, log in using an SSH
>> session without being logged on on the console)? If that doesn't  
>> work,
>> it  shouldn't work either with and without the LSUIElement key.
>
> Right.  But it also means that there are more things than appscript
> which can cause this.

Of course, there are various API's that cause this effect and  
appscript is not
the only user of those APIs.

To rephrase my question: can you start the daemon program without
being logged on to the console and check if it works at all (both with  
and
without the LSUIElement being set)?

That's something I cannot test with appscript because that can't work
without being logged on to the console as it needs to access other  
running
applications to work.

Ronald


From janssen at parc.com  Thu Feb  5 18:35:08 2009
From: janssen at parc.com (Bill Janssen)
Date: Thu, 5 Feb 2009 09:35:08 PST
Subject: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
In-Reply-To: <4AE8366C-A45E-48F9-9C95-4824DC2C4CCF@mac.com>
References: <73365.1233593908@parc.com>
	<50F04F2A-E03A-4726-8A4E-A2E61F4B5794@mac.com>
	<93649.1233679741@parc.com>
	<20960264-74A5-4CB7-BFF7-1093DC265A18@mac.com>
	<12522.1233769848@parc.com>
	<C1252394-37FD-4089-BB07-3C5CA344F4FA@mac.com>
	<16584.1233786366@parc.com>
	<2FC01A3C-640C-4DAB-8521-D51D660E738C@mac.com>
	<63075.1233849876@parc.com>
	<4AE8366C-A45E-48F9-9C95-4824DC2C4CCF@mac.com>
Message-ID: <63767.1233855308@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> To rephrase my question: can you start the daemon program without
> being logged on to the console and check if it works at all (both with
> and
> without the LSUIElement being set)?

It's an extremely complicated program, running a number of threads, and
running both the Python VM and the Java VM (though it seems to be a
Python code piece that's causing this).  So "works" is a relative
measure.  It does seem to work without anyone logged in, but the piece
that's accessing some framework which is causing the promotion may not
be exercised in this state.  I've narrowed it down to 8 possible Python
modules, which if I remove will cause the promotion not to happen, and
verified that none of them import appscript, directly or indirectly.

I'll post more when I know more...

Bill

From nathan.stocks at gmail.com  Thu Feb  5 19:12:20 2009
From: nathan.stocks at gmail.com (Nathan)
Date: Thu, 5 Feb 2009 11:12:20 -0700
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
In-Reply-To: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
References: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
Message-ID: <96c9d6a80902051012o4ae8d7a0q2706434f2105d5b1@mail.gmail.com>

On Tue, Feb 3, 2009 at 6:27 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> Hi,
>
> I'm going to Pycon this year and I'm wondering if anyone is interested in
> doing a MacPython related sprint afterwards. Possible topics:
>
> * Investigate OSX-integration issues (such as the "rocket icon" that
> sometimes appears)
>
> * Get Py2app development going again
>
> * Packaging 3th-party extensions (especially those using non-system C
> libraries) for OSX. That is, how to do the package collection on
> pythonmac.org correctly.
>
> * PyObjC
>
> Ronald

I won't be going, but I wanted to lend my moral support by stating
that that all looks like great stuff to work on!  :-)

~ Nathan

From rowen at u.washington.edu  Thu Feb  5 21:32:47 2009
From: rowen at u.washington.edu (Russell E. Owen)
Date: Thu, 05 Feb 2009 12:32:47 -0800
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
References: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
Message-ID: <rowen-AC7E36.12324705022009@news.gmane.org>

In article <A238A3C1-02D1-4840-9EDA-53EFD4DCB338 at mac.com>,
 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> Hi,
> 
> I'm going to Pycon this year and I'm wondering if anyone is interested  
> in doing a MacPython related sprint afterwards. Possible topics:
> 
> * Investigate OSX-integration issues (such as the "rocket icon" that  
> sometimes appears)
> 
> * Get Py2app development going again
> 
> * Packaging 3th-party extensions (especially those using non-system C  
> libraries) for OSX. That is, how to do the package collection on  
> pythonmac.org correctly.

Sounds great. Any chance of releasing a new macholib as well (so we 
don't have to use the dev version to avoid the Leopard? svn 1.5? issues)

-- Russell


From gary.bernhardt at gmail.com  Fri Feb  6 00:08:30 2009
From: gary.bernhardt at gmail.com (Gary Bernhardt)
Date: Thu, 5 Feb 2009 18:08:30 -0500
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
In-Reply-To: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
References: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
Message-ID: <9c34c72e0902051508g3dfdb848s632fc368ef50b7f0@mail.gmail.com>

2009/2/3 Ronald Oussoren <ronaldoussoren at mac.com>:
> Hi,
>
> I'm going to Pycon this year and I'm wondering if anyone is interested in
> doing a MacPython related sprint afterwards. Possible topics:

I may stay for the sprints. If I am, I'd definitely be interested in
helping out. No guarantees yet, though. :)

> * Investigate OSX-integration issues (such as the "rocket icon" that
> sometimes appears)
>
> * Get Py2app development going again
>
> * Packaging 3th-party extensions (especially those using non-system C
> libraries) for OSX. That is, how to do the package collection on
> pythonmac.org correctly.
>
> * PyObjC

-- 
Gary
http://blog.extracheese.org

From jaromir.siska at gmail.com  Fri Feb  6 22:40:49 2009
From: jaromir.siska at gmail.com (Jaromir Siska)
Date: Fri, 6 Feb 2009 18:40:49 -0300
Subject: [Pythonmac-SIG] PyObjC
Message-ID: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>

I would like to ask if anybody knows what is happening with PyObjC. Is the
project still alive? On the project WEB pages has nothing happened in the
past 10 months.

Thank you for any information!
Regards
Jaromir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090206/81be7f0d/attachment.htm>

From andrea.gavana at gmail.com  Sat Feb  7 02:14:34 2009
From: andrea.gavana at gmail.com (Andrea Gavana)
Date: Sat, 7 Feb 2009 01:14:34 +0000
Subject: [Pythonmac-SIG] Possible GUI2Exe Improvements?
Message-ID: <d5ff27200902061714u741c1612k7698a86ec9e1b9f2@mail.gmail.com>

Hi All,

    I released yesterday a new version of GUI2Exe:

http://code.google.com/p/gui2exe/

which doesn't really contain any new feature but just a simple fix for
Windows platforms. But today I was thinking about it: if there is
still someone using it, does he/she have any new suggestion on what to
add/improve/modify to enhance the application? Do you have any feature
request you would like to be included in GUI2Exe? If the answer is
"yes", please let me know :-D

Sorry for the huge cross-post and for wasting bandwidth ;-)

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

From bryanabsmith at gmail.com  Sat Feb  7 05:00:44 2009
From: bryanabsmith at gmail.com (Bryan Smith)
Date: Fri, 6 Feb 2009 23:00:44 -0500
Subject: [Pythonmac-SIG] XML Parsing
Message-ID: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>

Hi everyone,

I have another question I'm hoping someone would be kind enough to answer. I
am new to parsing XML (not to mention much of Python itself) and I am trying
to parse an XML file. The file I am trying to parse is this one:
http://ws.audioscrobbler.com/2.0/user/bryansmith/topalbums.xml.

So far, I have written up a class for parsing this file in my attempts to
present to the user a list of top albums on their last.fm profile. If you
note, the artist name and album name are both signified by the <name> tag
which makes my job harder. If the tag names were different, I wouldn't have
a problem. Listed below is the class I have written to parse the file. My
question then is this: is there a way I can say something like "if tag_name
== album name tag then....elif tag_name == artist name tag....". I hope this
is clear.

As it stands right now, if I parse this file and print the results, this is
what I get (understandably) if I try to print out in the following fashion -
album (playcount): Vheissu (332), Thrice (289), The Artist in the Ambulance
(286), Thrice (210) and so on. Thrice is the artist name. I want to be able
to differentiate between the "artist" name tag and the "album" name tag.


Class as it stands right now:

class GetTopAlbums(ContentHandler):

    in_album_tag = False
    in_playcount_tag = False

    def __init__(self, album, playcount):
        ContentHandler.__init__(self)
        self.album = album
        self.playcount = playcount
        self.data = []

    def startElement(self, tag_name, attr):
        if tag_name == "name":
            self.in_album_tag = True
        elif tag_name == "playcount":
            self.in_playcount_tag = True

    def endElement(self, tag_name):
        if tag_name == "name":
            content = "".join(self.data)
            self.data = []
            self.album.append(content)
            self.in_album_tag = False
        elif tag_name == "playcount":
            content = "".join(self.data)
            self.data = []
            self.playcount.append(content)
            self.in_playcount_tag = False

    def characters(self, string):
        if self.in_album_tag == True:
            self.data.append(string)
        elif self.in_playcount_tag == True:
            self.data.append(string)

Thanks in advance!
Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090206/f1e1dc1b/attachment.htm>

From pythonmac at rebertia.com  Sat Feb  7 05:06:42 2009
From: pythonmac at rebertia.com (Chris Rebert)
Date: Fri, 6 Feb 2009 20:06:42 -0800
Subject: [Pythonmac-SIG] XML Parsing
In-Reply-To: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>
References: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>
Message-ID: <50697b2c0902062006l698ef2e5rdf5f90b6012cf8da@mail.gmail.com>

On Fri, Feb 6, 2009 at 8:00 PM, Bryan Smith <bryanabsmith at gmail.com> wrote:
> Hi everyone,
>
> I have another question I'm hoping someone would be kind enough to answer. I
> am new to parsing XML (not to mention much of Python itself) and I am trying
> to parse an XML file. The file I am trying to parse is this one:
> http://ws.audioscrobbler.com/2.0/user/bryansmith/topalbums.xml.

How exactly does this relate to Python on Mac OS X specifically? You'd
definitely get more people to look at (and answer) your question if
you posted it to python-list/c.l.p instead of here (where it's not
really all that relevant).

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com

From sdm7g at mac.com  Sat Feb  7 08:18:21 2009
From: sdm7g at mac.com (Steve Majewski)
Date: Sat, 07 Feb 2009 02:18:21 -0500
Subject: [Pythonmac-SIG] XML Parsing
In-Reply-To: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>
References: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>
Message-ID: <9C54782E-A149-4548-A630-090D7745BD7E@mac.com>


Not clear from your question whether your goal is to learn to parse  
XML in python
or to solve a particular problem. If your goal is to learn python XML  
processing,
then go right ahead -- however, it looks like you are using SAX below,  
and the sort
of thing you describe might be done better using a DOM parser ( or  
maybe etree )

If what you want is not just to select some info from the xml file,  
but to get it
into a Python object so that you can then manipulate it further, then  
DOM or etree
is also probably a better model. It will parse the XML ( likely using  
SAX underneath )
and give you an object that encodes the whole file.

[ Not that it can't be done in SAX -- it's just that, as you  
discovered, low level
   SAX parsing requires that you keep track of the containment  
hierarchy yourself,
   which is a lot of work to solve a simple problem. ]


If you're just trying to work with XML, then most folks don't write  
XML parsers for
that sort of thing, but use higher level tools: XSLT, XPATH and or  
XQUERY.

The Mac has xsltproc as a built-in xslt (1.0) processor.
There is a xpath program written in perl in Leopard/10.5. ( /usr/bin/ 
xpath )
And Saxon is easily downloaded and does xslt 2.0 and xquery 1.0 .


The following XSLT 1.0 stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  
version="1.0">
<xsl:output method="text"/>

<xsl:template match="/">
     <xsl:apply-templates select="/topalbums/album[@rank &lt; 6]"/>
     <!-- just select the top 5 albums -->
</xsl:template>

<xsl:template match="/topalbums/album" >
   album: <xsl:value-of select="name"/>
   artist: <xsl:value-of select="artist/name"/>
   count=<xsl:value-of select="playcount"/>
   <xsl:text>
   </xsl:text> <!-- this is here to insert the blank line break -->
</xsl:template>

</xsl:stylesheet>


Will, when run on that file, produce this output:
~$ xsltproc Untitled1.xsl  topalbums.xml

   album: Vheissu
   artist: Thrice
   count=332

   album: The Artist in the Ambulance
   artist: Thrice
   count=289

   album: Appeal To Reason
   artist: Rise Against
   count=286

   album: Favourite Worst Nightmare
   artist: Arctic Monkeys
   count=210

   album: The Sufferer & The Witness
   artist: Rise Against
   count=206

[ Not sure if that's anything like what you want. ]


I'm sure that the whole thing would reduce to an even more concise  
XQuery request.

I was trying to do the whole thing as an xpath one liner, but it  
didn't like
my attempts to include alternates in parenthesis. I think this is an  
xpath 1.0
vs. xpath 2.0 issue. Saxon is the only thing that supports 2.0. The  
perl, python
and java libraries only support xpath 1.0.

This sort of expression did work using xpath 2.0 (in oxygen editor):

	//album[@rank < 6]/(name|playcount|artist/name)

But I couldn't figure out a 1.0 syntax that would grab all three fields.

( and the perl xpath seems to have a bug that interprets '@rank < 6'  
as less-than-or-equal! )


-- Steve Majewski



On Feb 6, 2009, at 11:00 PM, Bryan Smith wrote:

> Hi everyone,
>
> I have another question I'm hoping someone would be kind enough to  
> answer. I am new to parsing XML (not to mention much of Python  
> itself) and I am trying to parse an XML file. The file I am trying  
> to parse is this one: http://ws.audioscrobbler.com/2.0/user/bryansmith/topalbums.xml 
> .
>
> So far, I have written up a class for parsing this file in my  
> attempts to present to the user a list of top albums on their  
> last.fm profile. If you note, the artist name and album name are  
> both signified by the <name> tag which makes my job harder. If the  
> tag names were different, I wouldn't have a problem. Listed below is  
> the class I have written to parse the file. My question then is  
> this: is there a way I can say something like "if tag_name == album  
> name tag then....elif tag_name == artist name tag....". I hope this  
> is clear.
>
> As it stands right now, if I parse this file and print the results,  
> this is what I get (understandably) if I try to print out in the  
> following fashion - album (playcount): Vheissu (332), Thrice (289),  
> The Artist in the Ambulance (286), Thrice (210) and so on. Thrice is  
> the artist name. I want to be able to differentiate between the  
> "artist" name tag and the "album" name tag.
>
>
> Class as it stands right now:
>
> class GetTopAlbums(ContentHandler):
>
>     in_album_tag = False
>     in_playcount_tag = False
>
>     def __init__(self, album, playcount):
>         ContentHandler.__init__(self)
>         self.album = album
>         self.playcount = playcount
>         self.data = []
>
>     def startElement(self, tag_name, attr):
>         if tag_name == "name":
>             self.in_album_tag = True
>         elif tag_name == "playcount":
>             self.in_playcount_tag = True
>
>     def endElement(self, tag_name):
>         if tag_name == "name":
>             content = "".join(self.data)
>             self.data = []
>             self.album.append(content)
>             self.in_album_tag = False
>         elif tag_name == "playcount":
>             content = "".join(self.data)
>             self.data = []
>             self.playcount.append(content)
>             self.in_playcount_tag = False
>
>     def characters(self, string):
>         if self.in_album_tag == True:
>             self.data.append(string)
>         elif self.in_playcount_tag == True:
>             self.data.append(string)
>
> Thanks in advance!
> Bryan
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From bryanabsmith at gmail.com  Sat Feb  7 21:09:35 2009
From: bryanabsmith at gmail.com (Bryan Smith)
Date: Sat, 7 Feb 2009 15:09:35 -0500
Subject: [Pythonmac-SIG] XML Parsing
In-Reply-To: <9C54782E-A149-4548-A630-090D7745BD7E@mac.com>
References: <f49ad29d0902062000w6f352337re7980b1d09b87d2a@mail.gmail.com>
	<9C54782E-A149-4548-A630-090D7745BD7E@mac.com>
Message-ID: <f49ad29d0902071209r22e73a52p6f13804bd4d48133@mail.gmail.com>

"Not clear from your question whether your goal is to learn to parse XML in
python
or to solve a particular problem. If your goal is to learn python XML
processing,
then go right ahead -- however, it looks like you are using SAX below, and
the sort
of thing you describe might be done better using a DOM parser ( or maybe
etree )" - It's a bit of both - learning XML parsing through solving a
problem. I started with SAX because that's how the book I have does it.

I have looked up ElementTree and this looks like a much easier and much more
elegant solution to my problem.

"Not that it can't be done in SAX -- it's just that, as you discovered, low
level
 SAX parsing requires that you keep track of the containment hierarchy
yourself,
 which is a lot of work to solve a simple problem." - I see now that I was
doing a lot more work than I really needed to to accomplish my goal.

Thanks a lot Steve for the in-depth (from my perspective) explanation of all
the solutions available to me. I appreciate the help.

Bryan

On Sat, Feb 7, 2009 at 2:18 AM, Steve Majewski <sdm7g at mac.com> wrote:

>
> Not clear from your question whether your goal is to learn to parse XML in
> python
> or to solve a particular problem. If your goal is to learn python XML
> processing,
> then go right ahead -- however, it looks like you are using SAX below, and
> the sort
> of thing you describe might be done better using a DOM parser ( or maybe
> etree )
>
> If what you want is not just to select some info from the xml file, but to
> get it
> into a Python object so that you can then manipulate it further, then DOM
> or etree
> is also probably a better model. It will parse the XML ( likely using SAX
> underneath )
> and give you an object that encodes the whole file.
>
> [ Not that it can't be done in SAX -- it's just that, as you discovered,
> low level
>  SAX parsing requires that you keep track of the containment hierarchy
> yourself,
>  which is a lot of work to solve a simple problem. ]
>
>
> If you're just trying to work with XML, then most folks don't write XML
> parsers for
> that sort of thing, but use higher level tools: XSLT, XPATH and or XQUERY.
>
> The Mac has xsltproc as a built-in xslt (1.0) processor.
> There is a xpath program written in perl in Leopard/10.5. ( /usr/bin/xpath
> )
> And Saxon is easily downloaded and does xslt 2.0 and xquery 1.0 .
>
>
> The following XSLT 1.0 stylesheet:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
> <xsl:output method="text"/>
>
> <xsl:template match="/">
>    <xsl:apply-templates select="/topalbums/album[@rank &lt; 6]"/>
>    <!-- just select the top 5 albums -->
> </xsl:template>
>
> <xsl:template match="/topalbums/album" >
>  album: <xsl:value-of select="name"/>
>  artist: <xsl:value-of select="artist/name"/>
>  count=<xsl:value-of select="playcount"/>
>  <xsl:text>
>  </xsl:text> <!-- this is here to insert the blank line break -->
> </xsl:template>
>
> </xsl:stylesheet>
>
>
> Will, when run on that file, produce this output:
> ~$ xsltproc Untitled1.xsl  topalbums.xml
>
>  album: Vheissu
>  artist: Thrice
>  count=332
>
>  album: The Artist in the Ambulance
>  artist: Thrice
>  count=289
>
>  album: Appeal To Reason
>  artist: Rise Against
>  count=286
>
>  album: Favourite Worst Nightmare
>  artist: Arctic Monkeys
>  count=210
>
>  album: The Sufferer & The Witness
>  artist: Rise Against
>  count=206
>
> [ Not sure if that's anything like what you want. ]
>
>
> I'm sure that the whole thing would reduce to an even more concise XQuery
> request.
>
> I was trying to do the whole thing as an xpath one liner, but it didn't
> like
> my attempts to include alternates in parenthesis. I think this is an xpath
> 1.0
> vs. xpath 2.0 issue. Saxon is the only thing that supports 2.0. The perl,
> python
> and java libraries only support xpath 1.0.
>
> This sort of expression did work using xpath 2.0 (in oxygen editor):
>
>        //album[@rank < 6]/(name|playcount|artist/name)
>
> But I couldn't figure out a 1.0 syntax that would grab all three fields.
>
> ( and the perl xpath seems to have a bug that interprets '@rank < 6' as
> less-than-or-equal! )
>
>
> -- Steve Majewski
>
>
>
>
> On Feb 6, 2009, at 11:00 PM, Bryan Smith wrote:
>
>  Hi everyone,
>>
>> I have another question I'm hoping someone would be kind enough to answer.
>> I am new to parsing XML (not to mention much of Python itself) and I am
>> trying to parse an XML file. The file I am trying to parse is this one:
>> http://ws.audioscrobbler.com/2.0/user/bryansmith/topalbums.xml.
>>
>> So far, I have written up a class for parsing this file in my attempts to
>> present to the user a list of top albums on their last.fm profile. If you
>> note, the artist name and album name are both signified by the <name> tag
>> which makes my job harder. If the tag names were different, I wouldn't have
>> a problem. Listed below is the class I have written to parse the file. My
>> question then is this: is there a way I can say something like "if tag_name
>> == album name tag then....elif tag_name == artist name tag....". I hope this
>> is clear.
>>
>> As it stands right now, if I parse this file and print the results, this
>> is what I get (understandably) if I try to print out in the following
>> fashion - album (playcount): Vheissu (332), Thrice (289), The Artist in the
>> Ambulance (286), Thrice (210) and so on. Thrice is the artist name. I want
>> to be able to differentiate between the "artist" name tag and the "album"
>> name tag.
>>
>>
>> Class as it stands right now:
>>
>> class GetTopAlbums(ContentHandler):
>>
>>    in_album_tag = False
>>    in_playcount_tag = False
>>
>>    def __init__(self, album, playcount):
>>        ContentHandler.__init__(self)
>>        self.album = album
>>        self.playcount = playcount
>>        self.data = []
>>
>>    def startElement(self, tag_name, attr):
>>        if tag_name == "name":
>>            self.in_album_tag = True
>>        elif tag_name == "playcount":
>>            self.in_playcount_tag = True
>>
>>    def endElement(self, tag_name):
>>        if tag_name == "name":
>>            content = "".join(self.data)
>>            self.data = []
>>            self.album.append(content)
>>            self.in_album_tag = False
>>        elif tag_name == "playcount":
>>            content = "".join(self.data)
>>            self.data = []
>>            self.playcount.append(content)
>>            self.in_playcount_tag = False
>>
>>    def characters(self, string):
>>        if self.in_album_tag == True:
>>            self.data.append(string)
>>        elif self.in_playcount_tag == True:
>>            self.data.append(string)
>>
>> Thanks in advance!
>> Bryan
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090207/1568cd58/attachment.htm>

From imagine512 at gmail.com  Sun Feb  8 08:32:55 2009
From: imagine512 at gmail.com (Jacob)
Date: Sat, 7 Feb 2009 23:32:55 -0800
Subject: [Pythonmac-SIG] py2app - After building for distribution,
	No module named PyObjCTools
Message-ID: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>

Hi guys,
I'm have a little trouble with py2app when building an app for distribution.
 I'll give an example using one of the py2app/pyobjc2 examples,
ICSharingWatcher.  I setup Python 2.5.4 using MacPorts 1.7.0, along with the
following packages:

py25-bdist_mpkg @0.4.3_0 (active)
py25-macholib-devel @1.2_0 (active)
py25-modulegraph-devel @0.7.2_0 (active)
py25-py2app-devel @0.4.2_1 (active)
py25-pyobjc2 @2.0_1 (active)
py25-pyobjc2-cocoa @2.0_1 (active)
py25-setuptools @0.6c9_0 (active)
py25-zlib @2.5.4_0 (active)
python25 @2.5.4_0+darwin_9+macosx (active)
python_select @0.2.1_0+darwin_9 (active)
  * Some other modules were removed for brevity.

With the MacPorts version selected, in the ICSharingWatcher example, if I
execute "python setup.py py2app", I get the following error message:

  pkg_resources.DistributionNotFound: pyobjc

If I modify "setup.py" and change "install_requires=["pyobjc"]," to
"install_requires=["pyobjc-core"]," or just comment out the line, then I can
successfully build the example.  However, on startup it complains
"ImportError: No module named PyObjCTools".

I can clean up the build and dist directories, execute "python setup.py
py2app -A" with this modified setup.py and the example runs just fine.  I
can run MacPort's python and import PyObjCTools without a problem.  So, it
seems that I'm just not telling py2app how to correctly include PyObjCTools.

Any ideas why the "pyobjc" package cannot be found?  I'm running 10.5.6 and
have XCode 3.1.2 installed.

Thanks,
Jacob

--------------------------------------------------
For reference, the setup.py in the example looks like:

from setuptools import setup

setup(
    data_files=['MainMenu.nib'],
    app=['ICSharingWatcher.py'],
    install_requires=["pyobjc"],
    setup_requires=["py2app"],
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090207/341cf563/attachment-0001.htm>

From jaromir.siska at gmail.com  Sun Feb  8 17:44:43 2009
From: jaromir.siska at gmail.com (Jaromir Siska)
Date: Sun, 8 Feb 2009 13:44:43 -0300
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
Message-ID: <e33d6b580902080844s436b908fm9765bd20291ce130@mail.gmail.com>

Hi Ronald,

I can?t attend this year Pycon nevertheless I am interested in the topics
that you propose and prepared to participate and provide my help. If there
is anything specific at this moment or as an outcome of MacPython sprint
please contact me on the email jaromir.siska at gmail.com. I am particularly
interested in further development of PyObjC.

Jaromir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090208/fe9cd851/attachment.htm>

From listsin at integrateddevcorp.com  Sun Feb  8 17:25:57 2009
From: listsin at integrateddevcorp.com (s s)
Date: Sun, 8 Feb 2009 11:25:57 -0500
Subject: [Pythonmac-SIG] py2app - After building for distribution,
	No module named PyObjCTools
In-Reply-To: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
Message-ID: <4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>

I have had similar problems with the "ImportError: No module named  
PyObjCTools" and actually sent my entire project to someone who was  
distributing a (beta) commercial product for some help.

He spent 4 hours on it, hacked the hell out of the startup modules and  
everything else and got it to build on his machine, then I couldn't  
duplicate his results on mine.

py2app needs some serious attention on the 10.5.6 stack and I'm  
willing to help get it going -- I just don't have the domain knowledge  
to get the ball rolling though I'm sure I could help keep it rolling  
once I knew where to poke the stick.

S
>
On Feb 8, 2009, at 2:32 AM, Jacob wrote:

> Hi guys,
>
> I'm have a little trouble with py2app when building an app for  
> distribution.  I'll give an example using one of the py2app/pyobjc2  
> examples, ICSharingWatcher.  I setup Python 2.5.4 using MacPorts  
> 1.7.0, along with the following packages:
>
> py25-bdist_mpkg @0.4.3_0 (active)
> py25-macholib-devel @1.2_0 (active)
> py25-modulegraph-devel @0.7.2_0 (active)
> py25-py2app-devel @0.4.2_1 (active)
> py25-pyobjc2 @2.0_1 (active)
> py25-pyobjc2-cocoa @2.0_1 (active)
> py25-setuptools @0.6c9_0 (active)
> py25-zlib @2.5.4_0 (active)
> python25 @2.5.4_0+darwin_9+macosx (active)
> python_select @0.2.1_0+darwin_9 (active)
>  * Some other modules were removed for brevity.
>
> With the MacPorts version selected, in the ICSharingWatcher example,  
> if I execute "python setup.py py2app", I get the following error  
> message:
>
>  pkg_resources.DistributionNotFound: pyobjc
>
> If I modify "setup.py" and change "install_requires=["pyobjc"]," to  
> "install_requires=["pyobjc-core"]," or just comment out the line,  
> then I can successfully build the example.  However, on startup it  
> complains "ImportError: No module named PyObjCTools".
>
> I can clean up the build and dist directories, execute "python  
> setup.py py2app -A" with this modified setup.py and the example runs  
> just fine.  I can run MacPort's python and import PyObjCTools  
> without a problem.  So, it seems that I'm just not telling py2app  
> how to correctly include PyObjCTools.
>
> Any ideas why the "pyobjc" package cannot be found?  I'm running  
> 10.5.6 and have XCode 3.1.2 installed.
>
> Thanks,
> Jacob
>
> --------------------------------------------------
> For reference, the setup.py in the example looks like:
>
> from setuptools import setup
>
> setup(
>    data_files=['MainMenu.nib'],
>    app=['ICSharingWatcher.py'],
>    install_requires=["pyobjc"],
>    setup_requires=["py2app"],
> )
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From ggpolo at gmail.com  Tue Feb 10 03:08:05 2009
From: ggpolo at gmail.com (Guilherme Polo)
Date: Tue, 10 Feb 2009 00:08:05 -0200
Subject: [Pythonmac-SIG] Conditional code in _tkinter and tkappinit for Mac,
	no longer needed 	?
Message-ID: <ac2200130902091808s1fd591e9pa7ad836903527c77@mail.gmail.com>

Hi there,

I was wondering if someone around could help me test something on mac
? Specifically this conditional code in Modules/_tkinter.c and
Modules/tkappinit.c for TK_AQUA. I've talked with some people and
apparently starting with tk 8.4.7 (the one bundled with mac osx 10.5,
right ?) they should go, otherwise they could even cause bad troubles
(like abort()s, as it is happening with two mac osx 10.5 buildslaves).

There is this patch http://bugs.python.org/file13000/oldtkaqua.diff
attached on issue5120, so if anyone could give it a try on
python-trunk and tell if it works, or if it doesn't make any
difference, or anything I would thank you very much. I would try this
myself, but I don't own a mac :)

I hope this list is not totally wrong for this, it seemed the right place.

Regards,

-- 
-- Guilherme H. Polo Goncalves

From nad at acm.org  Tue Feb 10 05:39:14 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 09 Feb 2009 20:39:14 -0800
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
Message-ID: <nad-A5EF39.20391409022009@news.gmane.org>

I've opened the following issues for problems with various menu, key 
definitions, and launch problems with IDLE.app and bin/idle on OS X:
  <http://bugs.python.org/issue5194>
  <http://bugs.python.org/issue5195>
  <http://bugs.python.org/issue5196>

Issue5194 applies to 2.6, trunk (2.7), 3.0, and py3k (3.1).  It might 
also work on 2.5 with a little touchup.

Issue5195 and Issue5196 are specific to Python 3.0 and py3k (3.1).

The patches included have been tested on 2.6, 2.7, 3.0, and 3.1 as 
indicated.  I believe that, with these patches applied, IDLE.app and 
command line idle (bin/idle) on all of these systems will exhibit
the same behavior regarding menus and key definitions.[1]  In 
particular, the often missing-in-action Preferences menu option should 
be home for good.

I'd appreciate feedback on the patches.  It would be best to comment 
directly via the issue tracker.


[1] One minor difference: bin/idle still has an application name of 
"Python" in menus and the dock while IDLE.app is "IDLE".

-- 
 Ned Deily,
 nad at acm.org


From ronaldoussoren at mac.com  Tue Feb 10 11:27:57 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Feb 2009 11:27:57 +0100
Subject: [Pythonmac-SIG] MacPython sprint at PyCon'09?
In-Reply-To: <rowen-AC7E36.12324705022009@news.gmane.org>
References: <A238A3C1-02D1-4840-9EDA-53EFD4DCB338@mac.com>
	<rowen-AC7E36.12324705022009@news.gmane.org>
Message-ID: <786FF2F2-EE72-44AB-A930-221B24BCD5BB@mac.com>


On 5 Feb, 2009, at 21:32, Russell E. Owen wrote:

> In article <A238A3C1-02D1-4840-9EDA-53EFD4DCB338 at mac.com>,
> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>> Hi,
>>
>> I'm going to Pycon this year and I'm wondering if anyone is  
>> interested
>> in doing a MacPython related sprint afterwards. Possible topics:
>>
>> * Investigate OSX-integration issues (such as the "rocket icon" that
>> sometimes appears)
>>
>> * Get Py2app development going again
>>
>> * Packaging 3th-party extensions (especially those using non-system C
>> libraries) for OSX. That is, how to do the package collection on
>> pythonmac.org correctly.
>
> Sounds great. Any chance of releasing a new macholib as well (so we
> don't have to use the dev version to avoid the Leopard? svn 1.5?  
> issues)

I'll have to ping Bob about that, I don't have enough privileges to  
actually push out new releases.

Ronald

From ronaldoussoren at mac.com  Tue Feb 10 11:29:35 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Feb 2009 11:29:35 +0100
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
Message-ID: <E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>


On 6 Feb, 2009, at 22:40, Jaromir Siska wrote:

> I would like to ask if anybody knows what is happening with PyObjC.  
> Is the project still alive? On the project WEB pages has nothing  
> happened in the past 10 months.

The project is still alive, and moving forward but not very fast. I've  
been busy with other things, and am more focussed on getting  
development going again than updating the website. Updating that (and  
actually doing a release again) is on my todo list though.

Ronald


From ronaldoussoren at mac.com  Tue Feb 10 11:40:21 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Feb 2009 11:40:21 +0100
Subject: [Pythonmac-SIG] py2app - After building for distribution,
 No module named PyObjCTools
In-Reply-To: <4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
	<4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
Message-ID: <5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>


On 8 Feb, 2009, at 17:25, s s wrote:

> I have had similar problems with the "ImportError: No module named  
> PyObjCTools" and actually sent my entire project to someone who was  
> distributing a (beta) commercial product for some help.
>
> He spent 4 hours on it, hacked the hell out of the startup modules  
> and everything else and got it to build on his machine, then I  
> couldn't duplicate his results on mine.
>
> py2app needs some serious attention on the 10.5.6 stack and I'm  
> willing to help get it going -- I just don't have the domain  
> knowledge to get the ball rolling though I'm sure I could help keep  
> it rolling once I knew where to poke the stick.

One of the things I'd like to see is a set of functional tests for  
py2app, even if that only consists of a collection of sample  
applications that use the various libraries in common use, such as:

* A PyObjC application
* A wxWidgets application
* ...
* Applications using matplotlib
* Applications using other libraries that sometimes cause problems.

Lack of a proper testing infrastructure is a major issue for py2app at  
the moment, it is way to easy to accidently break something when   
changing the py2app code base. Having a set of test applications would  
at least make it easier to ensure that nothing gets accidently broken.

W.r.t. PyObjCTools issue: I'm currently working on better tests for  
the core functionality and framework wrappers for PyObjC and will work  
on fixing issues related to the examples when that's done (including  
fixing py2app where needed).

Ronald
>
>
> S
>>
> On Feb 8, 2009, at 2:32 AM, Jacob wrote:
>
>> Hi guys,
>>
>> I'm have a little trouble with py2app when building an app for  
>> distribution.  I'll give an example using one of the py2app/pyobjc2  
>> examples, ICSharingWatcher.  I setup Python 2.5.4 using MacPorts  
>> 1.7.0, along with the following packages:
>>
>> py25-bdist_mpkg @0.4.3_0 (active)
>> py25-macholib-devel @1.2_0 (active)
>> py25-modulegraph-devel @0.7.2_0 (active)
>> py25-py2app-devel @0.4.2_1 (active)
>> py25-pyobjc2 @2.0_1 (active)
>> py25-pyobjc2-cocoa @2.0_1 (active)
>> py25-setuptools @0.6c9_0 (active)
>> py25-zlib @2.5.4_0 (active)
>> python25 @2.5.4_0+darwin_9+macosx (active)
>> python_select @0.2.1_0+darwin_9 (active)
>> * Some other modules were removed for brevity.
>>
>> With the MacPorts version selected, in the ICSharingWatcher  
>> example, if I execute "python setup.py py2app", I get the following  
>> error message:
>>
>> pkg_resources.DistributionNotFound: pyobjc
>>
>> If I modify "setup.py" and change "install_requires=["pyobjc"]," to  
>> "install_requires=["pyobjc-core"]," or just comment out the line,  
>> then I can successfully build the example.  However, on startup it  
>> complains "ImportError: No module named PyObjCTools".
>>
>> I can clean up the build and dist directories, execute "python  
>> setup.py py2app -A" with this modified setup.py and the example  
>> runs just fine.  I can run MacPort's python and import PyObjCTools  
>> without a problem.  So, it seems that I'm just not telling py2app  
>> how to correctly include PyObjCTools.
>>
>> Any ideas why the "pyobjc" package cannot be found?  I'm running  
>> 10.5.6 and have XCode 3.1.2 installed.
>>
>> Thanks,
>> Jacob
>>
>> --------------------------------------------------
>> For reference, the setup.py in the example looks like:
>>
>> from setuptools import setup
>>
>> setup(
>>   data_files=['MainMenu.nib'],
>>   app=['ICSharingWatcher.py'],
>>   install_requires=["pyobjc"],
>>   setup_requires=["py2app"],
>> )
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From listsin at integrateddevcorp.com  Tue Feb 10 14:51:42 2009
From: listsin at integrateddevcorp.com (s s)
Date: Tue, 10 Feb 2009 08:51:42 -0500
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
Message-ID: <2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>

I could help out with the website.

Is there somewhere to download the site as it currently exists?

Thanks,

S

On Feb 10, 2009, at 5:29 AM, Ronald Oussoren wrote:

>
> On 6 Feb, 2009, at 22:40, Jaromir Siska wrote:
>
>> I would like to ask if anybody knows what is happening with PyObjC.  
>> Is the project still alive? On the project WEB pages has nothing  
>> happened in the past 10 months.
>
> The project is still alive, and moving forward but not very fast.  
> I've been busy with other things, and am more focussed on getting  
> development going again than updating the website. Updating that  
> (and actually doing a release again) is on my todo list though.
>
> Ronald
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From orestis at orestis.gr  Tue Feb 10 15:07:19 2009
From: orestis at orestis.gr (Orestis Markou)
Date: Tue, 10 Feb 2009 14:07:19 +0000
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
	<2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
Message-ID: <dabdc63f0902100607w3966e332mc57a395b12962f6b@mail.gmail.com>

Unless I'm very wrong, I think that
http://svn.red-bean.com/pyobjc/trunk/pyobjc/pyobjc-website/ is used to
generate the website.

There is also http://svn.red-bean.com/pyobjc/trunk/pyobjc-web/ but it
seems to be obsolete - perhaps it should be deleted to avoid
confusion?

Orestis

On Tue, Feb 10, 2009 at 1:51 PM, s s <listsin at integrateddevcorp.com> wrote:
> I could help out with the website.
>
> Is there somewhere to download the site as it currently exists?
>
> Thanks,
>
> S
>
> On Feb 10, 2009, at 5:29 AM, Ronald Oussoren wrote:
>
>>
>> On 6 Feb, 2009, at 22:40, Jaromir Siska wrote:
>>
>>> I would like to ask if anybody knows what is happening with PyObjC. Is
>>> the project still alive? On the project WEB pages has nothing happened in
>>> the past 10 months.
>>
>> The project is still alive, and moving forward but not very fast. I've
>> been busy with other things, and am more focussed on getting development
>> going again than updating the website. Updating that (and actually doing a
>> release again) is on my todo list though.
>>
>> Ronald
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



-- 
orestis at orestis.gr
http://orestis.gr

From ronaldoussoren at mac.com  Tue Feb 10 15:08:15 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Feb 2009 15:08:15 +0100
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
	<2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
Message-ID: <AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>


On 10 Feb, 2009, at 14:51, s s wrote:

> I could help out with the website.
>
> Is there somewhere to download the site as it currently exists?

It's in the pyobjc-website module in the pyobjc repository.

I'm also experimenting with Trac on my machine, it's issue tracker is  
much better than SF and would make it easier for others to contribute  
to the website.   One thing I haven't found a good solution for is  
webedition of the PyObjC examples (such as <http://pyobjc.sourceforge.net/examples/pyobjc-framework-ScreenSaver/SillyBallsSaver/index.html 
 >), I'd like to keep that part of the side while keeping the source  
code in Subversion.

Ronald

>
>
> Thanks,
>
> S
>
> On Feb 10, 2009, at 5:29 AM, Ronald Oussoren wrote:
>
>>
>> On 6 Feb, 2009, at 22:40, Jaromir Siska wrote:
>>
>>> I would like to ask if anybody knows what is happening with  
>>> PyObjC. Is the project still alive? On the project WEB pages has  
>>> nothing happened in the past 10 months.
>>
>> The project is still alive, and moving forward but not very fast.  
>> I've been busy with other things, and am more focussed on getting  
>> development going again than updating the website. Updating that  
>> (and actually doing a release again) is on my todo list though.
>>
>> Ronald
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>


From listsin at integrateddevcorp.com  Tue Feb 10 15:46:25 2009
From: listsin at integrateddevcorp.com (s s)
Date: Tue, 10 Feb 2009 09:46:25 -0500
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
	<2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
	<AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>
Message-ID: <030C9CFD-9A5B-4B63-ABB3-14DF003ACDEA@integrateddevcorp.com>


On Feb 10, 2009, at 9:08 AM, Ronald Oussoren wrote:

>
> On 10 Feb, 2009, at 14:51, s s wrote:
>
>> I could help out with the website.
>>
>> Is there somewhere to download the site as it currently exists?
>
> It's in the pyobjc-website module in the pyobjc repository.

Found it.  Looks like you're set up to rsync it to the SF server.  If  
that's all the code then we'd probably be better off moving it all  
into Trac's wiki format.

> I'm also experimenting with Trac on my machine, it's issue tracker  
> is much better than SF and would make it easier for others to  
> contribute to the website.

Yes, the issue tracker's fine and having the site in a wiki format  
(spam protected, of course) would go a long way towards letting anyone  
with an interest help keep it up to date.

> One thing I haven't found a good solution for is webedition of the  
> PyObjC examples (such as <http://pyobjc.sourceforge.net/examples/pyobjc-framework-ScreenSaver/SillyBallsSaver/index.html 
> >), I'd like to keep that part of the side while keeping the source  
> code in Subversion.

A perfect project for a trac-hack though I've not personally ever done  
one.  Shouldn't be that big a deal and it is Python, after all...

Any particular reason to leave the svn repository on red-bean?  Might  
be nice to make a clean break and move the whole thing and all new  
development to some dedicated Trac hosting service.

Anyone know what's the de-facto Track hosting option for open source  
projects?

S
AKA ssteiner at mac.com



From kw at codebykevin.com  Tue Feb 10 16:03:04 2009
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 10 Feb 2009 10:03:04 -0500
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
In-Reply-To: <nad-A5EF39.20391409022009@news.gmane.org>
References: <nad-A5EF39.20391409022009@news.gmane.org>
Message-ID: <49919728.6020003@codebykevin.com>

Ned Deily wrote:

> The patches included have been tested on 2.6, 2.7, 3.0, and 3.1 as 
> indicated.  I believe that, with these patches applied, IDLE.app and 
> command line idle (bin/idle) on all of these systems will exhibit
> the same behavior regarding menus and key definitions.[1]  In 
> particular, the often missing-in-action Preferences menu option should 
> be home for good.

My version of IDLE (Python 2.6.1, Tk 8.5.3) shows the preferences menu 
just fine, under the IDLE application menu. (Right under "About IDLE." )

I submitted a patch on this a year or two ago because recent versions of 
Tk Aqua (> 8.4.14) hard-code in the "preferences" menu in that location, 
and IDLE was showing it twice. My patch tested for the Tk version and 
then loaded only one prefs menu.

I'm not sure if trunk versions of Python have broken this or not, but 
please confirm the patch is needed before applying it.

> 
> [1] One minor difference: bin/idle still has an application name of 
> "Python" in menus and the dock while IDLE.app is "IDLE".
> 

That's a function of the Aqua environment--when IDLE is double-clicked 
from an app bundle, it's IDLE.app; when it's run from the command-line, 
it's run by Python.app. Can't be avoided.

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

From nad at acm.org  Tue Feb 10 19:20:06 2009
From: nad at acm.org (Ned Deily)
Date: Tue, 10 Feb 2009 10:20:06 -0800
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<49919728.6020003@codebykevin.com>
Message-ID: <nad-0BF216.10200610022009@news.gmane.org>

In article <49919728.6020003 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:
> Ned Deily wrote: 
> > The patches included have been tested on 2.6, 2.7, 3.0, and 3.1 as 
> > indicated.  I believe that, with these patches applied, IDLE.app and 
> > command line idle (bin/idle) on all of these systems will exhibit
> > the same behavior regarding menus and key definitions.[1]  In 
> > particular, the often missing-in-action Preferences menu option should 
> > be home for good.
> My version of IDLE (Python 2.6.1, Tk 8.5.3) shows the preferences menu 
> just fine, under the IDLE application menu. (Right under "About IDLE." )
> 
> I submitted a patch on this a year or two ago because recent versions of 
> Tk Aqua (> 8.4.14) hard-code in the "preferences" menu in that location, 
> and IDLE was showing it twice. My patch tested for the Tk version and 
> then loaded only one prefs menu.
> 
> I'm not sure if trunk versions of Python have broken this or not, but 
> please confirm the patch is needed before applying it.

That code is still there and should be unaffected by the new patches. 
The check for Tk Aqua >= 8.4.14 takes a different path and 
unconditionally adds the Preferences menu.  For earlier versions of Tk, 
like the Apple-supplied one in 10.5 and with which the python.org 2.6.1 
distribution is built, the menu altering fails in IDLE.app because of a 
premature import during initialization in idlemain.  There are other 
menu issues addressed: for instance, bin/idle may have the Preferences 
menu but may also have a Options->Configure menu and a Windows (instead 
of Window) menu.

Let me know if you run into any problems building with a non-Apple 
Tcl/Tk.

> > [1] One minor difference: bin/idle still has an application name of 
> > "Python" in menus and the dock while IDLE.app is "IDLE". 
> That's a function of the Aqua environment--when IDLE is double-clicked 
> from an app bundle, it's IDLE.app; when it's run from the command-line, 
> it's run by Python.app. Can't be avoided.

Well, one *could* cheat a bit, something like:

$ cat idle
#!/bin/sh
open -a '/Applications/Python 2.6/IDLE.app' $@

To me, that's actually simpler in concept than what goes on under the 
covers to launch IDLE.app itself.

-- 
 Ned Deily,
 nad at acm.org


From jwt at OnJapan.net  Tue Feb 10 20:06:50 2009
From: jwt at OnJapan.net (Jim Tittsler)
Date: Wed, 11 Feb 2009 08:06:50 +1300
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>	<2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
	<AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>
Message-ID: <4991D04A.8050809@OnJapan.net>

On 02/11/2009 03:08 AM, Ronald Oussoren wrote:
> I'm also experimenting with Trac on my machine, it's issue tracker is
> much better than SF and would make it easier for others to contribute to
> the website.[...]

Don't overlook the fact that SourceForge now offers Trac as a "hosted 
app" (and even uses its wiki to host a lot of the SF documentation).  It 
is easy for projects to "opt-in" and use a copy.
   http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps

From ronaldoussoren at mac.com  Tue Feb 10 20:25:05 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 10 Feb 2009 20:25:05 +0100
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <030C9CFD-9A5B-4B63-ABB3-14DF003ACDEA@integrateddevcorp.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
	<2BB6C545-2AE3-4217-BFC8-1865059CA398@integrateddevcorp.com>
	<AA7489E1-0EEF-47A8-8748-58570876AA5E@mac.com>
	<030C9CFD-9A5B-4B63-ABB3-14DF003ACDEA@integrateddevcorp.com>
Message-ID: <570D6B2E-C574-4824-B4DA-EFF752E91DCC@mac.com>


On 10 Feb, 2009, at 15:46, s s wrote:

>
> On Feb 10, 2009, at 9:08 AM, Ronald Oussoren wrote:
>
>>
>> On 10 Feb, 2009, at 14:51, s s wrote:
>>
>>> I could help out with the website.
>>>
>>> Is there somewhere to download the site as it currently exists?
>>
>> It's in the pyobjc-website module in the pyobjc repository.
>
> Found it.  Looks like you're set up to rsync it to the SF server.   
> If that's all the code then we'd probably be better off moving it  
> all into Trac's wiki format.

Not quite, I'd prefer to keep the core documentation in the repository  
as reStructuredText files, anything else (such as tips, tricks,  
pointers to users of PyObjC and other sites) can be in the wiki.

The "core documentation" is the technical documentation for the brige  
itself, the PyObjC intro and technical notes on the framework wrappers  
(such as http://pyobjc.sourceforge.net/documentation/pyobjc-framework-Quartz/api-notes.html) 
. These are closely tied to the actual implementation and need to be  
kept into sync with the actual implementation.

>
>
>> I'm also experimenting with Trac on my machine, it's issue tracker  
>> is much better than SF and would make it easier for others to  
>> contribute to the website.
>
> Yes, the issue tracker's fine and having the site in a wiki format  
> (spam protected, of course) would go a long way towards letting  
> anyone with an interest help keep it up to date.

Spamming is definitly an issue, but I'd prefer to limit editing at the  
start anyway (to anyone that bother's to ask for write access).
>
>
>> One thing I haven't found a good solution for is webedition of the  
>> PyObjC examples (such as <http://pyobjc.sourceforge.net/examples/pyobjc-framework-ScreenSaver/SillyBallsSaver/index.html 
>> >), I'd like to keep that part of the side while keeping the source  
>> code in Subversion.
>
> A perfect project for a trac-hack though I've not personally ever  
> done one.  Shouldn't be that big a deal and it is Python, after all...

That's what I thought as well.

>
>
> Any particular reason to leave the svn repository on red-bean?   
> Might be nice to make a clean break and move the whole thing and all  
> new development to some dedicated Trac hosting service.
>
> Anyone know what's the de-facto Track hosting option for open source  
> projects?

There is a Trac instance for PyObjC at red-bean.com, except that I  
recently broke that when I started experimenting with it. I will ask  
someone to fix that for me. I'd prefer to wait with that until I have  
a solution for the Examples portion of the site, I'm going to  
experiment with creating a track-hack for that.

The reason I like to wait a little is that the red-bean maintainers  
are volunteers and I don't want to bother them too much.

Ronald
>
>
> S
> AKA ssteiner at mac.com
>
>


From imagine512 at gmail.com  Wed Feb 11 05:19:42 2009
From: imagine512 at gmail.com (Jacob)
Date: Tue, 10 Feb 2009 20:19:42 -0800
Subject: [Pythonmac-SIG] py2app - After building for distribution,
	No 	module named PyObjCTools
In-Reply-To: <5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
	<4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
	<5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
Message-ID: <682a57f10902102019w4fc35d5cwc9f9b5cd7ef0ccea@mail.gmail.com>

Ronald,

Great to hear that you're working on better tests for PyObjCTools.  After
struggling for hours, I think I finally found the problem with the latest
py2app-devel (0.4.2) + pyobjc-cocoa (2.0.1) from MacPorts.  I found the
__init__.py file was missing from:

/opt/local/lib/python2.5/site-packages/PyObjCTools/

I downloaded the __init__.py file from the pyobjc SVN and plopped it in that
directory.  For reference, this file contains the following one line:

__import__('pkg_resources').declare_namespace(__name__)

Then, I modified my setup file so that it looks more like
install_requires=["pyobjc-core"].  Apparently PyObjC 2.0 broke the project
up into smaller packages and the name changed as well.  "pyobjc-core" and I
think "pyobjc-framework-cocoa" are the packages required to build the PyObjC
examples that were of interest to me.

Phew, I'm so glad this is finally working.  Good luck with the py2app
tests.  I for one will be grateful for your work

Thanks,
Jacob


On Tue, Feb 10, 2009 at 2:40 AM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
> On 8 Feb, 2009, at 17:25, s s wrote:
>
>  I have had similar problems with the "ImportError: No module named
>> PyObjCTools" and actually sent my entire project to someone who was
>> distributing a (beta) commercial product for some help.
>>
>> He spent 4 hours on it, hacked the hell out of the startup modules and
>> everything else and got it to build on his machine, then I couldn't
>> duplicate his results on mine.
>>
>> py2app needs some serious attention on the 10.5.6 stack and I'm willing to
>> help get it going -- I just don't have the domain knowledge to get the ball
>> rolling though I'm sure I could help keep it rolling once I knew where to
>> poke the stick.
>>
>
> One of the things I'd like to see is a set of functional tests for py2app,
> even if that only consists of a collection of sample applications that use
> the various libraries in common use, such as:
>
> * A PyObjC application
> * A wxWidgets application
> * ...
> * Applications using matplotlib
> * Applications using other libraries that sometimes cause problems.
>
> Lack of a proper testing infrastructure is a major issue for py2app at the
> moment, it is way to easy to accidently break something when  changing the
> py2app code base. Having a set of test applications would at least make it
> easier to ensure that nothing gets accidently broken.
>
> W.r.t. PyObjCTools issue: I'm currently working on better tests for the
> core functionality and framework wrappers for PyObjC and will work on fixing
> issues related to the examples when that's done (including fixing py2app
> where needed).
>
> Ronald
>
>
>>
>> S
>>
>>>
>>>  On Feb 8, 2009, at 2:32 AM, Jacob wrote:
>>
>>  Hi guys,
>>>
>>> I'm have a little trouble with py2app when building an app for
>>> distribution.  I'll give an example using one of the py2app/pyobjc2
>>> examples, ICSharingWatcher.  I setup Python 2.5.4 using MacPorts 1.7.0,
>>> along with the following packages:
>>>
>>> py25-bdist_mpkg @0.4.3_0 (active)
>>> py25-macholib-devel @1.2_0 (active)
>>> py25-modulegraph-devel @0.7.2_0 (active)
>>> py25-py2app-devel @0.4.2_1 (active)
>>> py25-pyobjc2 @2.0_1 (active)
>>> py25-pyobjc2-cocoa @2.0_1 (active)
>>> py25-setuptools @0.6c9_0 (active)
>>> py25-zlib @2.5.4_0 (active)
>>> python25 @2.5.4_0+darwin_9+macosx (active)
>>> python_select @0.2.1_0+darwin_9 (active)
>>> * Some other modules were removed for brevity.
>>>
>>> With the MacPorts version selected, in the ICSharingWatcher example, if I
>>> execute "python setup.py py2app", I get the following error message:
>>>
>>> pkg_resources.DistributionNotFound: pyobjc
>>>
>>> If I modify "setup.py" and change "install_requires=["pyobjc"]," to
>>> "install_requires=["pyobjc-core"]," or just comment out the line, then I can
>>> successfully build the example.  However, on startup it complains
>>> "ImportError: No module named PyObjCTools".
>>>
>>> I can clean up the build and dist directories, execute "python setup.py
>>> py2app -A" with this modified setup.py and the example runs just fine.  I
>>> can run MacPort's python and import PyObjCTools without a problem.  So, it
>>> seems that I'm just not telling py2app how to correctly include PyObjCTools.
>>>
>>> Any ideas why the "pyobjc" package cannot be found?  I'm running 10.5.6
>>> and have XCode 3.1.2 installed.
>>>
>>> Thanks,
>>> Jacob
>>>
>>> --------------------------------------------------
>>> For reference, the setup.py in the example looks like:
>>>
>>> from setuptools import setup
>>>
>>> setup(
>>>  data_files=['MainMenu.nib'],
>>>  app=['ICSharingWatcher.py'],
>>>  install_requires=["pyobjc"],
>>>  setup_requires=["py2app"],
>>> )
>>> _______________________________________________
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090210/6bc5f74a/attachment.htm>

From Chris.Barker at noaa.gov  Wed Feb 11 18:18:45 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 11 Feb 2009 09:18:45 -0800
Subject: [Pythonmac-SIG] py2app - After building for distribution,
 No module named PyObjCTools
In-Reply-To: <5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
	<4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
	<5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
Message-ID: <49930875.9090500@noaa.gov>

Ronald Oussoren wrote:
> One of the things I'd like to see is a set of functional tests for 
> py2app, even if that only consists of a collection of sample 
> applications that use the various libraries in common use, such as:

> * A wxWidgets application

I've got lot's of little wx apps we could use -- just tell me where to 
put them.

> * Applications using matplotlib

This is a bit tricky -- MPL uses multiple back-ends, so we might need:

one using wx
one using TK
one using the new Cocoa back-end.

At least we can stick with just numpy now!

> Lack of a proper testing infrastructure is a major issue for py2app at 
> the moment, it is way to easy to accidently break something when  
> changing the py2app code base. Having a set of test applications would 
> at least make it easier to ensure that nothing gets accidently broken.

Do you have any ideas about how to runs tests automatically? As many of 
these are GUI app issues, it would be nice to be able to test without 
having to do a bunch of point and clicking. Maybe just knowing they 
start without errors is good enough -- particularly if they are written 
so that the toolkit in question is well exercised, by default, at startup.

Also -- any plans to support eggs? I'm using py2app to bundle up a 
Pylons-based app (web framework). It makes heavy use of eggs (and 
pkg_resources, the real problem), and I had to write a lot of extra code 
to get everything I needed included.

It's worth looking at what bb-freeze is doing -- they're using 
modulegraph too. I'd like to see a py2app -- bbfreeze merger, in fact.

It seems the app building process has two distinct parts:

1) figuring out what to include

2) bundling it all up

(1) is pretty platform dependent, so I"d love to see it the same in a 
tool for all platforms.
   -- OK figuring out which shared libs to include is probably platform 
dependent...

(2) is going to b totally different on the different platforms, but 
we've got the basic code on all platforms now anyway.

I say this based on my recent experience bundling a challenging app for 
Mac an Windows -- I used py2exe and py2app. While they both have a 
similar API, as son as I needed to extend what they do on their own, I 
found that I needed to write totally separate code -- I'd love to no 
have to do that!

-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 Feb 11 19:52:11 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 11 Feb 2009 19:52:11 +0100
Subject: [Pythonmac-SIG] py2app - After building for distribution,
 No module named PyObjCTools
In-Reply-To: <49930875.9090500@noaa.gov>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
	<4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
	<5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
	<49930875.9090500@noaa.gov>
Message-ID: <780A7BDF-B5CA-4FCD-B4BA-9509C5831B5E@mac.com>


On 11 Feb, 2009, at 18:18, Christopher Barker wrote:
>
>
>> Lack of a proper testing infrastructure is a major issue for py2app  
>> at the moment, it is way to easy to accidently break something  
>> when  changing the py2app code base. Having a set of test  
>> applications would at least make it easier to ensure that nothing  
>> gets accidently broken.
>
> Do you have any ideas about how to runs tests automatically?

Not yet. Just testing application launching should be good enough to  
find most issues, but I'm afraid there will be some clicking  
involved.  The important bit is that there needs to be a clear way to  
test if everything still works.

>
> Also -- any plans to support eggs? I'm using py2app to bundle up a  
> Pylons-based app (web framework). It makes heavy use of eggs (and  
> pkg_resources, the real problem), and I had to write a lot of extra  
> code to get everything I needed included.

Egg-support is on my todolist, I intend to work on that when I'm at  
pycon.

>
>
> It's worth looking at what bb-freeze is doing -- they're using  
> modulegraph too. I'd like to see a py2app -- bbfreeze merger, in fact.
>
> It seems the app building process has two distinct parts:
>
> 1) figuring out what to include
>
> 2) bundling it all up
>
> (1) is pretty platform dependent, so I"d love to see it the same in  
> a tool for all platforms.
>  -- OK figuring out which shared libs to include is probably  
> platform dependent...

It should be possible to move all of that to a platform independent  
library, with plugins to detect shared libraries. That would be a  
worthwhile exercise because it is rather lame that every packaging  
tool needs to reinvent the wheel here.

Ronald


From ronaldoussoren at mac.com  Thu Feb 12 08:40:17 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 12 Feb 2009 08:40:17 +0100
Subject: [Pythonmac-SIG] py2app - After building for distribution,
 No module named PyObjCTools
In-Reply-To: <EFC1D508-6AB5-42FD-BB1C-8D50BA64DC78@u.washington.edu>
References: <682a57f10902072332m75ad901bj684e7fab78d3d89f@mail.gmail.com>
	<4854D9F7-6620-442A-952B-C679F37EC845@integrateddevcorp.com>
	<5750951E-7285-4EB7-A3F2-2ADD3EF73B87@mac.com>
	<49930875.9090500@noaa.gov>
	<780A7BDF-B5CA-4FCD-B4BA-9509C5831B5E@mac.com>
	<EFC1D508-6AB5-42FD-BB1C-8D50BA64DC78@u.washington.edu>
Message-ID: <6927840B-5464-4885-87D9-528E20D69451@mac.com>

	
On 12 Feb, 2009, at 5:28, R Fritz wrote:

> Could this perhaps be done via Apple Events, or even the  
> accessibility features?

That's a great idea. The accessibility features should allow us to  
control the GUI from a script, and GUI scripting shouldn't be  
problematic here because the UI's of the test programs don't need to  
evolve much over time. This might not get us 100% of the way (some  
bundling problems might cause drawing issues when a required component  
isn't present), but at this would at least help a lot.

We could also add test code to the application that checks if all  
required resources are actually present.  This might take some care to  
avoid accidently telling py2app what to include through the test code  
(e.g. don't use "import some.required.module" to check if a module is  
packed into the bundle, use the __import__ function instead).

I'll be at Pycon, including some of the sprint days aftwards.  
Focussing on py2app during the sprints start to be more and more of a  
good idea, that's something where a lot can be gained with relatively  
little interference between tasks.

Ronald

>
>
> Randolph Fritz
>  design machine group
>  architecture department
>  university of washington
> rfritz at u.washington.edu
>
> On Feb 11, 2009, at 10:52 AM, Ronald Oussoren wrote:
>
>> Just testing application launching should be good enough to find  
>> most issues, but I'm afraid there will be some clicking involved.
>


From omar.flores.i.t at gmail.com  Thu Feb 12 22:30:01 2009
From: omar.flores.i.t at gmail.com (O Flores)
Date: Thu, 12 Feb 2009 16:30:01 -0500
Subject: [Pythonmac-SIG] ImportError: No module named Foundation
Message-ID: <732a9f480902121330h7ec9600bn7a9a7a1238a8dc65@mail.gmail.com>

Hi there,

I am trying to run an script I found in
http://codelemur.wordpress.com/2007/11/07/controlling-itunes-with-python-cross-platform/

The problem is that I get an error importing Foundation.  Where is
Foundation located and how can I include in the search path?  Do I need to
upgrade AppleScript? My Mac runs OS X.

Thanks for the help.

Omar



# -*- coding: utf-8 -*-
import sys
from optparse import OptionParser

platform = sys.platform
print platform
if platform == "win32":
    import win32com.client
    iTunes = win32com.client.gencache.EnsureDispatch("iTunes.Application")

if platform == "darwin":
    from Foundation import *
    from ScriptingBridge import *
    iTunes =
SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

def previousTrack():
    if platform == "win32":
            iTunes.PreviousTrack()
    if platform == "darwin":
            iTunes.previousTrack()

...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090212/71ff0fd2/attachment.htm>

From orestis at orestis.gr  Thu Feb 12 22:49:54 2009
From: orestis at orestis.gr (Orestis Markou)
Date: Thu, 12 Feb 2009 21:49:54 +0000
Subject: [Pythonmac-SIG] ImportError: No module named Foundation
In-Reply-To: <732a9f480902121330h7ec9600bn7a9a7a1238a8dc65@mail.gmail.com>
References: <732a9f480902121330h7ec9600bn7a9a7a1238a8dc65@mail.gmail.com>
Message-ID: <34950DF9-27D2-4B91-913D-06E4F4DEE6CB@orestis.gr>

Foundation is a Obj-C framework, you'll need PyObjC to get that. If  
you use Leopard, it's pre-installed in the system python. A quick  
check is this:

 >>>import objc

If this works, 'import Foundation' should work.

I've no idea how to install PyObjC on Tiger, unfortunately.

Orestis
--
orestis at orestis.gr
http://orestis.gr/




On 12 Feb 2009, at 21:30, O Flores wrote:

> Hi there,
>
> I am trying to run an script I found in http://codelemur.wordpress.com/2007/11/07/controlling-itunes-with-python-cross-platform/
>
> The problem is that I get an error importing Foundation.  Where is  
> Foundation located and how can I include in the search path?  Do I  
> need to upgrade AppleScript? My Mac runs OS X.
>
> Thanks for the help.
>
> Omar
>
>
>
> # -*- coding: utf-8 -*-
> import sys
> from optparse import OptionParser
>
> platform = sys.platform
> print platform
> if platform == "win32":
>     import win32com.client
>     iTunes =  
> win32com.client.gencache.EnsureDispatch("iTunes.Application")
>
> if platform == "darwin":
>     from Foundation import *
>     from ScriptingBridge import *
>     iTunes =  
> SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
>
> def previousTrack():
>     if platform == "win32":
>             iTunes.PreviousTrack()
>     if platform == "darwin":
>             iTunes.previousTrack()
>
> ...
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From vip at avatar.com.au  Fri Feb 13 07:41:43 2009
From: vip at avatar.com.au (DavidW)
Date: Fri, 13 Feb 2009 17:41:43 +1100
Subject: [Pythonmac-SIG] resetting up-arrow
Message-ID: <98E5A8BD-D90D-4ACB-91BE-2D623C312FBC@avatar.com.au>

Hi all,

In MacPython 2.5 (standard pkg install) I've lost the up-arrow  
function/scrollback function to '^[[A'

Elegant as is is, it's not very friendly!

I'm pretty sure it used to work.
If I load macPython 2.4 (or vim or whatever) from the same shell, it  
behaves itself, so I'm guessing it's not a $TERM issue.

My question is, (apart from how do I make it behave as a  'back'  
button) what have I inadvertently done to cause it to happen.
Some weird collection of keystrokes?

thanks,

D.
MacBook Pro/OSX-10.5.6
____________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg




From kcin at grrargh.net  Sat Feb 14 15:33:12 2009
From: kcin at grrargh.net (Nick Taylor)
Date: Sun, 15 Feb 2009 01:33:12 +1100
Subject: [Pythonmac-SIG] PyObjC Automator Actions
Message-ID: <719C585A-A6DC-4508-AA8E-C1CDF1BB2588@grrargh.net>

Hi.
I've been programming in Python for a while, but I'm relatively new to  
PyObjC and Cocoa programming in general.

I've been working on an Automator action written in Python/PyObjC,  
which has so far been simple. Now I want to add an options view to the  
bundle, and Automator doesn't seem to pick up on it. I've used the  
same main.xib file that Xcode generates for regular Cocoa-based  
actions, and I'm including it using the data_files parameter on  
distutils.core.setup when I build the .action bundle using py2app. The  
setup call is included below.

setup(
    name='HelloWorld',
    plugin=['Automator.py'],
    data_files=["main.xib"],
    options=dict(py2app=dict(
        extension=".action",
        plist='Info.plist',
    )),
)

Everything builds correctly and the action is valid and runs, but the  
"Options" tab for the action in Automator is disabled.

If anyone could shed some light on where I'm going wrong it would be  
greatly appreciated.

Thanks.

Nick.

From hellyj at ucsd.edu  Mon Feb 16 00:12:54 2009
From: hellyj at ucsd.edu (Helly John J.)
Date: Sun, 15 Feb 2009 15:12:54 -0800
Subject: [Pythonmac-SIG] Problems with GDAL on OSX
Message-ID: <5760CFA6-C00D-435A-874F-22EF1F7C1376@ucsd.edu>

Hi.

I'm a newbie to python and am running:

OS X 10.5.6
Python 2.5.4

and have run easy_install for gdal like this:

/Library/Python/2.5/site-packages>sudo easy_install GDAL
Password:
Searching for GDAL
Best match: GDAL 1.6.0
Processing GDAL-1.6.0-py2.5-macosx-10.5-i386.egg
GDAL 1.6.0 is already the active version in easy-install.pth

Using /Library/Python/2.5/site-packages/GDAL-1.6.0-py2.5-macosx-10.5- 
i386.egg
Processing dependencies for GDAL
Finished processing dependencies for GDAL

However, when I run python and try to import gdal, this is what happens:

Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import gdal
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: No module named gdal
 >>>

Clearly, it's not being found but I don't understand how to debug this  
any further.  I have the *.egg in the site-packages directory but  
don't understand if there is something else I have to do to make it  
usable.  Any help would be much appreciated.

Cheers.
--------------
John Helly, University of California, San Diego
San Diego Supercomputer Center,  Mail Code 0527
Scripps Institution of Oceanography, Climate, Atmospheric Science, and  
Physical Oceanography, Mail Code 0224
9500 Gilman Dr., La Jolla CA 92093
+01 760 840 8660 mobile / stonesteps (Skype) / stonesteps7 (iChat) /  
URL (http://www.sdsc.edu/~hellyj)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090215/b61a7ad0/attachment.htm>

From scottclausen at mac.com  Mon Feb 16 03:50:35 2009
From: scottclausen at mac.com (Scott Clausen)
Date: Sun, 15 Feb 2009 18:50:35 -0800
Subject: [Pythonmac-SIG] Python 3 Update?
Message-ID: <C9F6935A-559D-446F-A9CB-6BE7018A64C0@mac.com>

Hello,

I'm new to the list and was wondering if Mac's can upgrade to Python v3.

Is it intel specific or will it work on a PowerPC chipped machine?

I'm currently using Python 2.6.1.

Thanks in advance.

Scott

From pythonmac at rebertia.com  Mon Feb 16 04:53:56 2009
From: pythonmac at rebertia.com (Chris Rebert)
Date: Sun, 15 Feb 2009 19:53:56 -0800
Subject: [Pythonmac-SIG] Python 3 Update?
In-Reply-To: <C9F6935A-559D-446F-A9CB-6BE7018A64C0@mac.com>
References: <C9F6935A-559D-446F-A9CB-6BE7018A64C0@mac.com>
Message-ID: <50697b2c0902151953v3375914eqccda2c1a78d4a863@mail.gmail.com>

On Sun, Feb 15, 2009 at 6:50 PM, Scott Clausen <scottclausen at mac.com> wrote:
> Hello,
>
> I'm new to the list and was wondering if Mac's can upgrade to Python v3.

http://python.org/ftp/python/3.0.1/python-3.0.1-macosx2009-02-14.dmg

Dunno whether it's Universal.

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com

From pythonnutter at gmail.com  Mon Feb 16 07:53:34 2009
From: pythonnutter at gmail.com (Python Nutter)
Date: Mon, 16 Feb 2009 17:53:34 +1100
Subject: [Pythonmac-SIG] Python 3 Update?
In-Reply-To: <50697b2c0902151953v3375914eqccda2c1a78d4a863@mail.gmail.com>
References: <C9F6935A-559D-446F-A9CB-6BE7018A64C0@mac.com>
	<50697b2c0902151953v3375914eqccda2c1a78d4a863@mail.gmail.com>
Message-ID: <af90b3410902152253l688c7323g706101a5c394fa97@mail.gmail.com>

It is bigger than any other package to download so that increases the
probability it might be universal with multiple CPU type binaries in
the one package.

2009/2/16 Chris Rebert <pythonmac at rebertia.com>:
> On Sun, Feb 15, 2009 at 6:50 PM, Scott Clausen <scottclausen at mac.com> wrote:
>> Hello,
>>
>> I'm new to the list and was wondering if Mac's can upgrade to Python v3.
>
> http://python.org/ftp/python/3.0.1/python-3.0.1-macosx2009-02-14.dmg
>
> Dunno whether it's Universal.
>
> Cheers,
> Chris

From nad at acm.org  Mon Feb 16 09:27:41 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 16 Feb 2009 00:27:41 -0800
Subject: [Pythonmac-SIG] Python 3 Update?
References: <C9F6935A-559D-446F-A9CB-6BE7018A64C0@mac.com>
	<50697b2c0902151953v3375914eqccda2c1a78d4a863@mail.gmail.com>
Message-ID: <nad-3401D6.00274116022009@ger.gmane.org>

In article 
<50697b2c0902151953v3375914eqccda2c1a78d4a863 at mail.gmail.com>,
 Chris Rebert <pythonmac at rebertia.com> wrote:

> On Sun, Feb 15, 2009 at 6:50 PM, Scott Clausen <scottclausen at mac.com> wrote:
> > Hello,
> >
> > I'm new to the list and was wondering if Mac's can upgrade to Python v3.
> 
> http://python.org/ftp/python/3.0.1/python-3.0.1-macosx2009-02-14.dmg
> 
> Dunno whether it's Universal.

It's 2-way "fat" Universal: i386 and ppc.  And should work on 10.3.9(?) 
on up.

-- 
 Ned Deily,
 nad at acm.org


From nad at acm.org  Mon Feb 16 09:56:02 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 16 Feb 2009 00:56:02 -0800
Subject: [Pythonmac-SIG] resetting up-arrow
References: <98E5A8BD-D90D-4ACB-91BE-2D623C312FBC@avatar.com.au>
Message-ID: <nad-94E866.00560216022009@ger.gmane.org>

In article <98E5A8BD-D90D-4ACB-91BE-2D623C312FBC at avatar.com.au>,
 DavidW <vip at avatar.com.au> wrote:

> In MacPython 2.5 (standard pkg install) I've lost the up-arrow  
> function/scrollback function to '^[[A'
> 
> Elegant as is is, it's not very friendly!
> 
> I'm pretty sure it used to work.
> If I load macPython 2.4 (or vim or whatever) from the same shell, it  
> behaves itself, so I'm guessing it's not a $TERM issue.
> 
> My question is, (apart from how do I make it behave as a  'back'  
> button) what have I inadvertently done to cause it to happen.
> Some weird collection of keystrokes?

I'm not sure I understand the problem you mean but it's possible it has 
to do with which of the two line-completion libraries the python you are 
using is linked with: gnu readline or bsd editline.  Generally, recent 
python.org pythons are linked with the former while Apple's built-in 
python has the latter.  Unfortunately, the two have different syntax.  
See for instance:

<http://article.gmane.org/gmane.comp.python.general/606317>

-- 
 Ned Deily,
 nad at acm.org


From nad at acm.org  Mon Feb 16 09:59:10 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 16 Feb 2009 00:59:10 -0800
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
References: <nad-A5EF39.20391409022009@news.gmane.org>
Message-ID: <nad-CC27EA.00591016022009@ger.gmane.org>

In article <nad-A5EF39.20391409022009 at news.gmane.org>,
 Ned Deily <nad at acm.org> wrote:
> I've opened the following issues for problems with various menu, key 
> definitions, and launch problems with IDLE.app and bin/idle on OS X:
>   <http://bugs.python.org/issue5194>
>   <http://bugs.python.org/issue5195>
>   <http://bugs.python.org/issue5196>
> 
> The patches included have been tested on 2.6, 2.7, 3.0, and 3.1 as 
> indicated.  I believe that, with these patches applied, IDLE.app and 
> command line idle (bin/idle) on all of these systems will exhibit
> the same behavior regarding menus and key definitions.[1]  In 
> particular, the often missing-in-action Preferences menu option should 
> be home for good.

FYI, those fixes have been included in Python 3.0.1 which was recently 
released.  An OS X installer image for 3.0.1 is available here:
<http://www.python.org/download/releases/3.0.1/>

The applicable fixes should also show up in the next 2.x releases.

-- 
 Ned Deily,
 nad at acm.org


From cygnusx1 at mac.com  Tue Feb 17 01:37:21 2009
From: cygnusx1 at mac.com (Tom Bridgman)
Date: Mon, 16 Feb 2009 19:37:21 -0500
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
In-Reply-To: <nad-CC27EA.00591016022009@ger.gmane.org>
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
Message-ID: <805E7543-96ED-474F-8059-123B4085C29D@mac.com>

Is there a reliable way to install python 3 on a Mac without damaging  
the resident installation?  Are there 10.4 vs 10.5 issues?

Tom
On Feb 16, 2009, at 3:59 AM, Ned Deily wrote:

> In article <nad-A5EF39.20391409022009 at news.gmane.org>,
>  Ned Deily <nad at acm.org> wrote:
>> I've opened the following issues for problems with various menu, key
>> definitions, and launch problems with IDLE.app and bin/idle on OS X:
>>   <http://bugs.python.org/issue5194>
>>   <http://bugs.python.org/issue5195>
>>   <http://bugs.python.org/issue5196>
>>
>> The patches included have been tested on 2.6, 2.7, 3.0, and 3.1 as
>> indicated.  I believe that, with these patches applied, IDLE.app and
>> command line idle (bin/idle) on all of these systems will exhibit
>> the same behavior regarding menus and key definitions.[1]  In
>> particular, the often missing-in-action Preferences menu option  
>> should
>> be home for good.
>
> FYI, those fixes have been included in Python 3.0.1 which was recently
> released.  An OS X installer image for 3.0.1 is available here:
> <http://www.python.org/download/releases/3.0.1/>
>
> The applicable fixes should also show up in the next 2.x releases.
>
> -- 
>  Ned Deily,
>  nad at acm.org
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From nad at acm.org  Tue Feb 17 05:07:08 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 16 Feb 2009 20:07:08 -0800
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
	<805E7543-96ED-474F-8059-123B4085C29D@mac.com>
Message-ID: <nad-A2CD2D.20070816022009@news.gmane.org>

In article <805E7543-96ED-474F-8059-123B4085C29D at mac.com>,
 Tom Bridgman <cygnusx1 at mac.com> wrote:
> Is there a reliable way to install python 3 on a Mac without damaging  
> the resident installation?  Are there 10.4 vs 10.5 issues?

It's easy to install multiple versions and there should be no danger of 
damage.

The python.org 3.0.1 should install on any 10.4 or 10.5 system (actually 
10.3.x as well, though I don't think that has been tested).  It will 
install the Python framework at /Library/Frameworks/Versions/3.0 and it 
will install the folder /Applications/Python 3.0.  In the latter folder 
will be IDLE, Update Shell Profile, and some Extras.  By default, the 
installer will *not* modify your shell profile to add python3.0 to your 
shell $PATH.  You can access 3.0 by launching the 3.0 IDLE.  If you want 
to use python3.0 from a shell without making it your default python, you 
can type in the full path.

/Library/Frameworks/Python.framework/Versions/3.0/bin/python3.0

Or you can create a shell alias to that path (see below).

If you do want to make python3.0 your default python, either edit your 
shell profile to add the path of the framework bin directory to the 
front of your PATH or click on the "Update Shell Profile" command to do 
it for you.

The python.org 2.x installers work exactly the same way, installing into 
/Library/Frameworks/Versions/2.x and /Applications/Python 2.6 (or 
/Applications/MacPython 2.x for 2.5 and earlier)  All versions can 
co-exist with each other and with the Apple-supplied python which lives 
in /System/Library/Versions/Python.framework/2.5 for 10.5 and 2.3 for 
10.4.  The Apple-supplied python is also linked to from /usr/bin/python.  
(Like everything else under /System, the python files there are managed 
by Apple and should remain undisturbed.)

So, depending on which pythons you have installed, you could set up 
shell aliases in your shell profile, like:

alias python3.0=\ 
"/Library/Frameworks/Python.framework/Versions/3.0/bin/python3.0"
alias python2.6=\ 
"/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6"
alias python2.5=\ 
"/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5"
alias applepython2.5=\ 
"/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5"
alias macportspython2.5=\
"/opt/local/bin/python2.5"
alias finkpython2.5=\
"/sw/bin/python2.5"
...

By default, each instance of python has its own site-packages directory, 
so when installing packages, you need to pay attention to which python 
you are running.  If you are installing by hand, make sure you install 
to the right python by doing something like:

   python3.0 setup.py ...

If you want to use easy_install, you'll probably need to install 
setuptools in each python version.  For the python.org 2.x versions, 
download from and follow the instructions here:
   <http://pypi.python.org/pypi/setuptools>
The 10.5 Apple python comes with setuptools pre-installed linked at 
/usr/bin/easy_install.  MacPorts and Fink have setuptools packages.  You 
may want to create aliases to the various easy_installs.  There isn't a 
supported 3.0 version of easy_install yet but people are working on it.

It would be nice to have a more intuitive way to manage the nest of 
pythons.  There will be likely be some discussion and perhaps some work 
on that at the upcoming Pycon.

I'm sure I'm missing some details here but I hope that gives you enough  
to feel comfortable exploring 3.0.

-- 
 Ned Deily,
 nad at acm.org


From nad at acm.org  Tue Feb 17 05:15:29 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 16 Feb 2009 20:15:29 -0800
Subject: [Pythonmac-SIG] IDLE fixes for 2.x and 3.x
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
	<805E7543-96ED-474F-8059-123B4085C29D@mac.com>
	<nad-A2CD2D.20070816022009@news.gmane.org>
Message-ID: <nad-781157.20152916022009@news.gmane.org>

In article <nad-A2CD2D.20070816022009 at news.gmane.org>,
 Ned Deily <nad at acm.org> wrote:
> [...]  All versions can 
> co-exist with each other and with the Apple-supplied python which lives 
> in 

/System/Library/Frameworks/Python.framework/Versions/2.5

> for 10.5 and 2.3 for 
> 10.4.
> [...]

-- 
 Ned Deily,
 nad at acm.org


From woklist at kyngchaos.com  Tue Feb 17 16:09:05 2009
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Tue, 17 Feb 2009 09:09:05 -0600
Subject: [Pythonmac-SIG] Problems with GDAL on OSX
In-Reply-To: <5760CFA6-C00D-435A-874F-22EF1F7C1376@ucsd.edu>
References: <5760CFA6-C00D-435A-874F-22EF1F7C1376@ucsd.edu>
Message-ID: <7443FE31-5A8E-40A6-80AA-2CAFDBFD8788@kyngchaos.com>

I guess I'll take a stab at this.  (I use my GDAL framework and python  
GDAL built from local source, not from easy_install.)

Do you have any form of GDAL installed?  The easy_install output isn't  
clear about if it found GDAL or not.  If it doesn't, it won't build  
the python extension, though you say it's there...  Maybe it will  
build it anyways, and hope that GDAL is found at runtime.

Another possibility is that it didn't install the compatibility python  
files.  The old GDAL python had everything at the root of the search  
path.  Now it's all in 'osgeo', so you should ge into the habit of  
importing like:

from osgeo import gdal

or even using a try/except to try both ways (see any of the GDAL  
python utility programs for an example).


Suggestion: try my GDAL framework - it comes with the python extension  
ready to use.  link in my sig.


On Feb 15, 2009, at 5:12 PM, Helly John J. wrote:

> Hi.
>
> I'm a newbie to python and am running:
>
> OS X 10.5.6
> Python 2.5.4
>
> and have run easy_install for gdal like this:
>
> /Library/Python/2.5/site-packages>sudo easy_install GDAL
> Password:
> Searching for GDAL
> Best match: GDAL 1.6.0
> Processing GDAL-1.6.0-py2.5-macosx-10.5-i386.egg
> GDAL 1.6.0 is already the active version in easy-install.pth
>
> Using /Library/Python/2.5/site-packages/GDAL-1.6.0-py2.5-macosx-10.5- 
> i386.egg
> Processing dependencies for GDAL
> Finished processing dependencies for GDAL
>
> However, when I run python and try to import gdal, this is what  
> happens:
>
> Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gdal
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: No module named gdal
> >>>
>
> Clearly, it's not being found but I don't understand how to debug  
> this any further.  I have the *.egg in the site-packages directory  
> but don't understand if there is something else I have to do to make  
> it usable.  Any help would be much appreciated.
>

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

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of  
the allied nations devoted an entire year exclusively to hating the  
____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war


From karstenwo at googlemail.com  Wed Feb 18 15:52:14 2009
From: karstenwo at googlemail.com (Karsten Wolf)
Date: Wed, 18 Feb 2009 15:52:14 +0100
Subject: [Pythonmac-SIG] Screen geometry
Message-ID: <66BF4F4A-BB67-47BC-8D99-F2FFC564D6DD@googlemail.com>

Hi,


how do I read the screen geometry (no of screens/monitors, coordinate  
rectangle for each) via python?

This is on OSX 10.4.11 PPC.


-karsten

From cygnusx1 at mac.com  Thu Feb 19 03:41:46 2009
From: cygnusx1 at mac.com (Tom Bridgman)
Date: Wed, 18 Feb 2009 21:41:46 -0500
Subject: [Pythonmac-SIG] Multiple python installation instructions (was IDLE
 fixes for 2.x and 3.x)
In-Reply-To: <nad-A2CD2D.20070816022009@news.gmane.org>
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
	<805E7543-96ED-474F-8059-123B4085C29D@mac.com>
	<nad-A2CD2D.20070816022009@news.gmane.org>
Message-ID: <DF176E17-7B45-4E84-880F-E4AE2621511D@mac.com>

I'm doing a presentation on travel next week so I won't try to  
install this until the following week, but this looks *very*  
straightforward and complete.

I don't find this posted on the http://wiki.python.org/moin/MacPython  
or on the FAQ, but it should be.

Thanks,
Tom
On Feb 16, 2009, at 11:07 PM, Ned Deily wrote:

> In article <805E7543-96ED-474F-8059-123B4085C29D at mac.com>,
>  Tom Bridgman <cygnusx1 at mac.com> wrote:
>> Is there a reliable way to install python 3 on a Mac without damaging
>> the resident installation?  Are there 10.4 vs 10.5 issues?
>
> It's easy to install multiple versions and there should be no  
> danger of
> damage.
>
> The python.org 3.0.1 should install on any 10.4 or 10.5 system  
> (actually
> 10.3.x as well, though I don't think that has been tested).  It will
> install the Python framework at /Library/Frameworks/Versions/3.0  
> and it
> will install the folder /Applications/Python 3.0.  In the latter  
> folder
> will be IDLE, Update Shell Profile, and some Extras.  By default, the
> installer will *not* modify your shell profile to add python3.0 to  
> your
> shell $PATH.  You can access 3.0 by launching the 3.0 IDLE.  If you  
> want
> to use python3.0 from a shell without making it your default  
> python, you
> can type in the full path.
>
> /Library/Frameworks/Python.framework/Versions/3.0/bin/python3.0
>
> Or you can create a shell alias to that path (see below).
>
> If you do want to make python3.0 your default python, either edit your
> shell profile to add the path of the framework bin directory to the
> front of your PATH or click on the "Update Shell Profile" command  
> to do
> it for you.
>
> The python.org 2.x installers work exactly the same way, installing  
> into
> /Library/Frameworks/Versions/2.x and /Applications/Python 2.6 (or
> /Applications/MacPython 2.x for 2.5 and earlier)  All versions can
> co-exist with each other and with the Apple-supplied python which  
> lives
> in /System/Library/Versions/Python.framework/2.5 for 10.5 and 2.3 for
> 10.4.  The Apple-supplied python is also linked to from /usr/bin/ 
> python.
> (Like everything else under /System, the python files there are  
> managed
> by Apple and should remain undisturbed.)
>
> So, depending on which pythons you have installed, you could set up
> shell aliases in your shell profile, like:
>
> alias python3.0=\
> "/Library/Frameworks/Python.framework/Versions/3.0/bin/python3.0"
> alias python2.6=\
> "/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6"
> alias python2.5=\
> "/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5"
> alias applepython2.5=\
> "/System/Library/Frameworks/Python.framework/Versions/2.5/bin/ 
> python2.5"
> alias macportspython2.5=\
> "/opt/local/bin/python2.5"
> alias finkpython2.5=\
> "/sw/bin/python2.5"
> ...
>
> By default, each instance of python has its own site-packages  
> directory,
> so when installing packages, you need to pay attention to which python
> you are running.  If you are installing by hand, make sure you install
> to the right python by doing something like:
>
>    python3.0 setup.py ...
>
> If you want to use easy_install, you'll probably need to install
> setuptools in each python version.  For the python.org 2.x versions,
> download from and follow the instructions here:
>    <http://pypi.python.org/pypi/setuptools>
> The 10.5 Apple python comes with setuptools pre-installed linked at
> /usr/bin/easy_install.  MacPorts and Fink have setuptools  
> packages.  You
> may want to create aliases to the various easy_installs.  There  
> isn't a
> supported 3.0 version of easy_install yet but people are working on  
> it.
>
> It would be nice to have a more intuitive way to manage the nest of
> pythons.  There will be likely be some discussion and perhaps some  
> work
> on that at the upcoming Pycon.
>
> I'm sure I'm missing some details here but I hope that gives you  
> enough
> to feel comfortable exploring 3.0.
>
> -- 
>  Ned Deily,
>  nad at acm.org
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From jaromir.siska at gmail.com  Thu Feb 19 08:11:14 2009
From: jaromir.siska at gmail.com (=?WINDOWS-1252?Q?Jarom=EDr_=8Ai=9Aka?=)
Date: Thu, 19 Feb 2009 08:11:14 +0100
Subject: [Pythonmac-SIG] PyObjC
In-Reply-To: <E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
References: <e33d6b580902061340na467ecv14139945291e6f1@mail.gmail.com>
	<E6FE1DF2-E28A-41EC-971B-755A78FF66EE@mac.com>
Message-ID: <A1481039-6447-4475-A4E1-256D26FF52E4@gmail.com>

Hi Ronald,

I apologize for my delayed responce caused by traveling in Patagonia  
and being out of Internet.

I am glad to hear that project is still alive. As I said in some of my  
previous mail if I can be of any help with development, please let me  
know.

Kind regards
Jaromir

On 10.2.2009, at 11:29, Ronald Oussoren wrote:

>
> On 6 Feb, 2009, at 22:40, Jaromir Siska wrote:
>
>> I would like to ask if anybody knows what is happening with PyObjC.  
>> Is the project still alive? On the project WEB pages has nothing  
>> happened in the past 10 months.
>
> The project is still alive, and moving forward but not very fast.  
> I've been busy with other things, and am more focussed on getting  
> development going again than updating the website. Updating that  
> (and actually doing a release again) is on my todo list though.
>
> Ronald
>


From Bernard.B.Yoo at aero.org  Thu Feb 19 19:58:12 2009
From: Bernard.B.Yoo at aero.org (Bernard B Yoo)
Date: Thu, 19 Feb 2009 10:58:12 -0800
Subject: [Pythonmac-SIG] py2app applications fails to find Pmw --- Low
 Sensitivity/Aerospace Internal Use Only
Message-ID: <OFF6F2B5AA.551B86B6-ON88257562.00653168-88257562.00683561@notes.aero.org>

Low Sensitivity/Aerospace Internal Use Only



I'm trying to create an .app from a .py file.  When I double-click the 
.app, I get a message saying Pmw was not found.

The commands I use are:

py2applet --make-setup myprogram.py
python setup.py py2app --packages Pmw

When I double-click the app icon, I get an error:

OSError: [Errno 20] Not a 
directory:'/Users/me/Documents/myprogram/bin/dist.myprogram.app/Contents/Resources/lib/python2.5/site-packages.zip/Pmw'

When I look in that directory, I see the site-packages.zip file AND a Pmw 
subdirectory.  Pmw is NOT included in site-packages.zip.

If I run the python setup.py py2app command with --include Pmw instead, 
the site-packages.zip file contains Pmw/__init__.pyc, but no other Pmw 
files.

I'm running MacOS X 10.5.6, Python 2.5.1, Pmw 1.3.

Suggestions are appreciated.  Thanks!

Low Sensitivity/Aerospace Internal Use Only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090219/5b10ee47/attachment.htm>

From airdrummer at wheel.org  Sat Feb 21 13:44:12 2009
From: airdrummer at wheel.org (tom wible)
Date: Sat, 21 Feb 2009 07:44:12 -0500
Subject: [Pythonmac-SIG] unicode problem w/pyapp 2.5 vs 2.6
In-Reply-To: <DF176E17-7B45-4E84-880F-E4AE2621511D@mac.com>
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
	<805E7543-96ED-474F-8059-123B4085C29D@mac.com>
	<nad-A2CD2D.20070816022009@news.gmane.org>
	<DF176E17-7B45-4E84-880F-E4AE2621511D@mac.com>
Message-ID: <499FF71C.3070700@wheel.org>

i've recently installed 2.6 on my minimac pvr, and it raised a unicode issue:

under 2.5, the filename returned from an applescript.app is plain text:

tomsdvr:/DVR/recordings dvr$ /usr/local/bin/python2.5
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import aem
 >>> playrec  = aem.Application(aem.findapp.byname('playRec'))
 >>> recIndx=22
 >>> [sfn, title, eptitle, descr, startDT, stopDT] = playrec.event('ascrpsbr', 
{'snam':'getiteminfo', '----': [recIndx]}).send()
 >>> sfn
u'New York Goes To War_Jan_17_2009__08_00_26-1_AM.m2t'
 >>>
 >>> startDT
'Saturday, January 17, 2009 8:00:00 AM'

but under 2.6:
tomsdvr:/DVR/recordings dvr$ python
Python 2.6.1 (r261:67515, Dec  6 2008, 16:42:21)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import aem
 >>> playrec  = aem.Application(aem.findapp.byname('playRec'))
 >>> [sfn, title, eptitle, descr, startDT, stopDT] = playrec.event('ascrpsbr', 
{'snam':'getiteminfo', '----': [recIndx]}).send()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name 'recIndx' is not defined
 >>> recIndx=31
 >>> [sfn, title, eptitle, descr, startDT, stopDT] = playrec.event('ascrpsbr', 
{'snam':'getiteminfo', '----': [recIndx]}).send()
 >>> sfn
u'\u4e00\u6500\u7700\u2000\u5900\u6f00\u7200\u6b00\u2000\u4700\u6f00\u6500\u7300\u2000\u5400\u6f00\u2000\u5700\u6100\u7200\u5f00\u4a00\u6100\u6e00\u5f00\u3100\u3700\u5f00\u3200\u3000\u3000\u3900\u5f00\u5f00\u3000\u3800\u5f00\u3000\u3000\u5f00\u3200\u3600\u2d00\u3100\u5f00\u4100\u4d00\u2e00\u6d00\u3200\u7400'
 >>> startDT
'Saturday, January 17, 2009 8:00:00 AM'


i had simply copied aem from the 2.5 site-packages to the 2.6's...is there 
something i missed in doing that? some data is ok (the dates)

From njriley at uiuc.edu  Sat Feb 21 14:06:03 2009
From: njriley at uiuc.edu (Nicholas Riley)
Date: Sat, 21 Feb 2009 07:06:03 -0600
Subject: [Pythonmac-SIG] unicode problem w/pyapp 2.5 vs 2.6
In-Reply-To: <499FF71C.3070700@wheel.org>
References: <nad-A5EF39.20391409022009@news.gmane.org>
	<nad-CC27EA.00591016022009@ger.gmane.org>
	<805E7543-96ED-474F-8059-123B4085C29D@mac.com>
	<nad-A2CD2D.20070816022009@news.gmane.org>
	<DF176E17-7B45-4E84-880F-E4AE2621511D@mac.com>
	<499FF71C.3070700@wheel.org>
Message-ID: <20090221130603.GA3470@uiuc.edu>

On Sat, Feb 21, 2009 at 07:44:12AM -0500, tom wible wrote:
> i had simply copied aem from the 2.5 site-packages to the 2.6's...is there 
> something i missed in doing that? some data is ok (the dates)

Looks like you might have a UCS-4 version of one Python and a UCS-2
version of the other.  Extension modules are not compatible between
the two, although usually you get a link error.

It's probably easiest just to reinstall install appscript on 2.6.

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

From lars at raeder.dk  Sat Feb 21 16:53:24 2009
From: lars at raeder.dk (Lars Clausen)
Date: Sat, 21 Feb 2009 16:53:24 +0100
Subject: [Pythonmac-SIG] 64-bit mode no work
Message-ID: <DEF20F43-12BB-4397-9214-8C6A292AF37E@raeder.dk>

I've been trying to get mod_python and mysql to work on my Intel  
MacBook Leopard, but with very little luck. Disliking the idea of  
turning my MySQL and Apache into 32-bit (seems backwards), I have  
installed 64-bit versions of everything:

Hedwig:~ larsrc$ file `which python`
/usr/bin/python: Mach-O 64-bit executable x86_64
Hedwig:~ larsrc$ file /usr/libexec/apache2/mod_python.so
/usr/libexec/apache2/mod_python.so: Mach-O 64-bit bundle x86_64
Hedwig:~ larsrc$ file /Library/WebServer/.python-eggs/ 
MySQL_python-1.2.2-py2.6-macosx-10.5-universal.egg-tmp/_mysql.so
/Library/WebServer/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5- 
universal.egg-tmp/_mysql.so: Mach-O universal binary with 4  
architectures
/Library/WebServer/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5- 
universal.egg-tmp/_mysql.so (for architecture i386):	Mach-O bundle i386
/Library/WebServer/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5- 
universal.egg-tmp/_mysql.so (for architecture ppc):	Mach-O bundle ppc
/Library/WebServer/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5- 
universal.egg-tmp/_mysql.so (for architecture ppc64):	Mach-O 64-bit  
bundle ppc64
/Library/WebServer/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5- 
universal.egg-tmp/_mysql.so (for architecture x86_64):	Mach-O 64-bit  
bundle x86_64
Hedwig:~ larsrc$ file `which httpd`
/usr/sbin/httpd: Mach-O 64-bit executable x86_64

Even so, when I try to load a .py page with mysqldb (using Publisher  
-- the real reason I want Python!), I get the infamous

File "/Library/WebServer/Documents/Python/test.py", line 4, in  
<module> import MySQLdb
File "build/bdist.macosx-10.5-universal/egg/MySQLdb/__init__.py", line  
19, in <module>
File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 7, in  
<module>
File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 6, in  
__bootstrap__
ImportError: dynamic module does not define init function (init_mysql)

I have been perusing a number of related pages (in order to get things  
to compile in the first place) that mostly seem to see this as a  
problem of 32/64-bit incompatibility, but with the entire stack being  
64-bit, surely it's something else. Any ideas?

Any ideas also why there is no 64-bit installation of Python for Mac?   
Given the presence of fat binaries, it seems like it would be a  
trivial task to have it.

As an aside, I got so fed up with trying to fix this that I switched  
briefly to IntelliJ + Java to implement my webservices. By the time I  
had gone through the tutorial to set up a sample web service, I had 6  
xml files in play but not a working web service. Publisher is just  
exemplary in its simplicity.

Thanks in advance,
-Lars


From nad at acm.org  Sat Feb 21 20:56:49 2009
From: nad at acm.org (Ned Deily)
Date: Sat, 21 Feb 2009 11:56:49 -0800
Subject: [Pythonmac-SIG] 64-bit mode no work
References: <DEF20F43-12BB-4397-9214-8C6A292AF37E@raeder.dk>
Message-ID: <nad-112A28.11564821022009@news.gmane.org>

In article <DEF20F43-12BB-4397-9214-8C6A292AF37E at raeder.dk>,
 Lars Clausen <lars at raeder.dk> wrote:
> I've been trying to get mod_python and mysql to work on my Intel  
> MacBook Leopard, but with very little luck. [...]

What about the MySQL library itself, i.e. libmysqlclient?  Do you have a 
64-bit version of it?  The standard distribution from MySQL is not 
4-way, (and, for 5.1.30 at least, it's broken for 2-way: 
<http://bugs.mysql.com/bug.php?id=41940>).

> Any ideas also why there is no 64-bit installation of Python for Mac?   
> Given the presence of fat binaries, it seems like it would be a  
> trivial task to have it.

The support for 4-way universal builds in python is relatively new.  
There has been some discussion recently on the python-dev list about 
providing "official" 4-way installers for OS X.  This will probably get 
discussed more at the upcoming PyCon.

-- 
 Ned Deily,
 nad at acm.org


From hengist.podd at virgin.net  Sat Feb 21 22:34:08 2009
From: hengist.podd at virgin.net (has)
Date: Sat, 21 Feb 2009 21:34:08 +0000
Subject: [Pythonmac-SIG] unicode problem w/pyapp 2.5 vs 2.6
Message-ID: <36ED6687-3023-4A5B-85C3-1777816513E1@virgin.net>

tom wible wrote:

> i've recently installed 2.6 on my minimac pvr, and it raised a  
> unicode issue:
>
> under 2.5, the filename returned from an applescript.app is plain  
> text:
> [...]
> >>> sfn
> u'New York Goes To War_Jan_17_2009__08_00_26-1_AM.m2t'
> [...]
> but under 2.6:
> [...]
>  >>> sfn
> u'\u4e00\u6500\u7700\u2000\u5900\u6f00\u7200\u6b00\u2000\u4700\u6f00\u6500\u7300\u2000\u5400\u6f00\u2000\u5700\u6100\u7200\u5f00\u4a00\u6100\u6e00\u5f00\u3100\u3700\u5f00\u3200\u3000\u3000\u3900\u5f00\u5f00\u3000\u3800\u5f00\u3000\u3000\u5f00\u3200\u3600\u2d00\u3100\u5f00\u4100\u4d00\u2e00\u6d00\u3200\u7400'
> [...]
> i had simply copied aem from the 2.5 site-packages to the 2.6's...is  
> there
> something i missed in doing that? some data is ok (the dates)

There's a known issue in Python 2.6's Unicode APIs; py-appscript  
0.19.0+ contains a workaround for this.

BTW, Python modules/extensions are not officially binary compatible  
across major Python releases, so you should be installing afresh anyway.

HTH

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From lars at raeder.dk  Sun Feb 22 19:04:40 2009
From: lars at raeder.dk (Lars Clausen)
Date: Sun, 22 Feb 2009 19:04:40 +0100
Subject: [Pythonmac-SIG] 64-bit mode no work
Message-ID: <378C26CA-4CF5-4DD6-B2BB-0D24B8AA7906@raeder.dk>


On Feb 22, 2009, at 12:00 PM, pythonmac-sig-request at python.org wrote:

>
> In article <DEF20F43-12BB-4397-9214-8C6A292AF37E at raeder.dk>,
> Lars Clausen <lars at raeder.dk> wrote:
>> I've been trying to get mod_python and mysql to work on my Intel
>> MacBook Leopard, but with very little luck. [...]
>
> What about the MySQL library itself, i.e. libmysqlclient?  Do you  
> have a
> 64-bit version of it?  The standard distribution from MySQL is not
> 4-way, (and, for 5.1.30 at least, it's broken for 2-way:
> <http://bugs.mysql.com/bug.php?id=41940>).

Hedwig:local larsrc$ ls -ld /usr/local/mysql*
lrwxr-xr-x   1 root  wheel   27 Feb 19 20:26 /usr/local/mysql ->  
mysql-5.0.77-osx10.5-x86_64
Hedwig:Sources larsrc$ file /usr/local/mysql-5.0.77-osx10.5-x86_64/lib/ 
libmysqlclient_r.15.0.0.dylib
/usr/local/mysql-5.0.77-osx10.5-x86_64/lib/libmysqlclient_r. 
15.0.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64

However, importing MySQLdb in python directly shows something  
interesting:

 >>> import MySQLdb
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "build/bdist.macosx-10.5-universal/egg/MySQLdb/__init__.py",  
line 19, in <module>
   File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 7, in  
<module>
   File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 6, in  
__bootstrap__
ImportError: dlopen(/Users/larsrc/.python-eggs/MySQL_python-1.2.2- 
py2.6-macosx-10.5-universal.egg-tmp/_mysql.so, 2): Library not  
loaded: /usr/local/mysql/lib/libmysqlclient_r.16.dylib
   Referenced from: /Users/larsrc/.python-eggs/MySQL_python-1.2.2- 
py2.6-macosx-10.5-universal.egg-tmp/_mysql.so
   Reason: image not found

It tries to fine the .16 version, but the 64-bit mysql has the .15  
version:

Hedwig:local larsrc$ locate libmysqlclient_r | grep .0.0
/usr/local/mysql-5.0.77-osx10.5-x86_64/lib/libmysqlclient_r.15.0.0.dylib
/usr/local/mysql-5.1.31-osx10.5-x86/lib/libmysqlclient_r.16.0.0.dylib

Linking /usr/local/mysql/lib/mysql and recompiling MySQLdb from fresh  
sources gave an egg that looks for the .15 version, but now it is back  
to the 'does not define init function'. No luck on that.

 >>> import MySQLdb
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "build/bdist.macosx-10.5-universal/egg/MySQLdb/__init__.py",  
line 19, in <module>
   File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 7, in  
<module>
   File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 6, in  
__bootstrap__
ImportError: dynamic module does not define init function (init_mysql)

I have cleared out my old eggs and checked that the egg used here is  
64-bit.

>>
>> Any ideas also why there is no 64-bit installation of Python for Mac?
>> Given the presence of fat binaries, it seems like it would be a
>> trivial task to have it.
>
> The support for 4-way universal builds in python is relatively new.
> There has been some discussion recently on the python-dev list about
> providing "official" 4-way installers for OS X.  This will probably  
> get
> discussed more at the upcoming PyCon.

I hope so. All this grief has had me casting about for another  
language to do really simple MySQL-to-JSON web services, but I have  
found nothing that does it as well as Python and Publisher.

-Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20090222/7a8ca671/attachment.htm>

From nad at acm.org  Sun Feb 22 23:26:15 2009
From: nad at acm.org (Ned Deily)
Date: Sun, 22 Feb 2009 14:26:15 -0800
Subject: [Pythonmac-SIG] 64-bit mode no work
References: <378C26CA-4CF5-4DD6-B2BB-0D24B8AA7906@raeder.dk>
Message-ID: <nad-D088E6.14261522022009@news.gmane.org>

In article <378C26CA-4CF5-4DD6-B2BB-0D24B8AA7906 at raeder.dk>,
 Lars Clausen <lars at raeder.dk> wrote:

Sorry, it's a bit difficult to tell what's going on here with all the 
changing pieces but one thing stands out: there's something very 
suspicious about the path names showing up in your tracebacks.  Note 
here:

> However, importing MySQLdb in python directly shows something  
> interesting:
>  >>> import MySQLdb
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "build/bdist.macosx-10.5-universal/egg/MySQLdb/__init__.py",  
> line 19, in <module>
>    File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 7, in  
> <module>
>    File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 6, in  
> __bootstrap__
> ImportError: dlopen(/Users/larsrc/.python-eggs/MySQL_python-1.2.2- 
> py2.6-macosx-10.5-universal.egg-tmp/_mysql.so, 2): Library not  
> loaded: /usr/local/mysql/lib/libmysqlclient_r.16.dylib
>    Referenced from: /Users/larsrc/.python-eggs/MySQL_python-1.2.2- 
> py2.6-macosx-10.5-universal.egg-tmp/_mysql.so
>    Reason: image not found
> It tries to fine the .16 version, but the 64-bit mysql has the .15  
> version:

The paths for the python files in MySQLdb do not look like they come 
from a normal installed egg.  Compare:
"build/bdist.macosx-10.5-universal/egg/_mysql.py"
to the path for the c extension:
"/Users/larsrc/.python-eggs/MySQL_python-1.2.2-py2.6-macosx-10.5-universa
l.egg-tmp/_mysql.so"
The latter looks correct.  _mysql.so and _mysql.py should  be in the 
same directory which probably explains the problem in your second 
example after rebuilding:

>  >>> import MySQLdb
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "build/bdist.macosx-10.5-universal/egg/MySQLdb/__init__.py",  
> line 19, in <module>
>    File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 7, in  
> <module>
>    File "build/bdist.macosx-10.5-universal/egg/_mysql.py", line 6, in  
> __bootstrap__
> ImportError: dynamic module does not define init function (init_mysql)

Depending on you settings, the installed egg may just be one zip file.  
If you look at the unzipped version, the layout of the top level of the 
egg should look something like this:

EGG-INFO/
MySQLdb/
_mysql.py*
_mysql.pyc
_mysql.pyo
_mysql.so*
_mysql_exceptions.py*
_mysql_exceptions.pyc
_mysql_exceptions.pyo

So it looks like there's something wrong with your sys.path here.  Are 
you using your python-64 to install the built egg to its site-packages 
directory?  It should just work.

cd build
/path/to/python-64 setup.py clean
/path/to/python-64 setup.py build
sudo /path/to/python-64 setup.py install

Don't know about the path for running under mod_python though.

-- 
 Ned Deily,
 nad at acm.org


From idan at pixane.net  Mon Feb 23 16:04:53 2009
From: idan at pixane.net (Idan Gazit)
Date: Mon, 23 Feb 2009 17:04:53 +0200
Subject: [Pythonmac-SIG] Uninstalling Python 2.6?
Message-ID: <A9D9FD92-E516-4F6E-AD15-E367FB8DCB95@pixane.net>

Hi Folks,

So a while back I tried installing (mac) python 2.6 on my leopard  
machine, mainly to poke around.

Today I'm trying out some xcode/pyobjc stuff and I've been tearing my  
hair out wondering why nothing works as advertised. Turns out that  
xcode was building against python 2.6, which doesn't have the relevant  
modules in its classpath (objc, for example).

A little bit of digging later and it seems that the *only* version of  
python listed in /Library/Frameworks/Python.framework is 2.6. Oh noes!

So my plea:

* How do I cleanly remove the 2.6 (installed using the provided  
installer) installation such that I'm left with my leopard-vanilla 2.5?
* What should I do about the Python.framework? I imagine that PyObjC  
apps require at least one version there. Did 2.6 overwrite the  
existing one? Can anybody tell me how to get it back or how to install  
the 2.5 version?


My head is spinning from all the googling I have done on the subject.  
I'm hoping that a few well-placed words of wisdom will help me here!

Yours in much confusion,

Idan

From orestis at orestis.gr  Mon Feb 23 17:04:37 2009
From: orestis at orestis.gr (Orestis Markou)
Date: Mon, 23 Feb 2009 16:04:37 +0000
Subject: [Pythonmac-SIG] Uninstalling Python 2.6?
In-Reply-To: <A9D9FD92-E516-4F6E-AD15-E367FB8DCB95@pixane.net>
References: <A9D9FD92-E516-4F6E-AD15-E367FB8DCB95@pixane.net>
Message-ID: <dabdc63f0902230804w56b76207xe59c2dc9cad7b2fa@mail.gmail.com>

I'm not on my Mac right now, but I think that the system python is
actually in /System/Library rather than in /Library. If that's the
case, I think you can just remove /Library/Frameworks/Python and
update /usr/bin/python to point to vanilla Python.

I would try renaming /Library/Frameworks/Python.framework and see if
this fixes your issues - if yes, you can then safely delete it.

I personally use MacPorts, that installs itself in /opt/local and only
fiddles with PATH, to avoid this kind of problem.

Orestis

On Mon, Feb 23, 2009 at 3:04 PM, Idan Gazit <idan at pixane.net> wrote:
> Hi Folks,
>
> So a while back I tried installing (mac) python 2.6 on my leopard machine,
> mainly to poke around.
>
> Today I'm trying out some xcode/pyobjc stuff and I've been tearing my hair
> out wondering why nothing works as advertised. Turns out that xcode was
> building against python 2.6, which doesn't have the relevant modules in its
> classpath (objc, for example).
>
> A little bit of digging later and it seems that the *only* version of python
> listed in /Library/Frameworks/Python.framework is 2.6. Oh noes!
>
> So my plea:
>
> * How do I cleanly remove the 2.6 (installed using the provided installer)
> installation such that I'm left with my leopard-vanilla 2.5?
> * What should I do about the Python.framework? I imagine that PyObjC apps
> require at least one version there. Did 2.6 overwrite the existing one? Can
> anybody tell me how to get it back or how to install the 2.5 version?
>
>
> My head is spinning from all the googling I have done on the subject. I'm
> hoping that a few well-placed words of wisdom will help me here!
>
> Yours in much confusion,
>
> Idan
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



-- 
orestis at orestis.gr
http://orestis.gr

From nad at acm.org  Mon Feb 23 23:28:30 2009
From: nad at acm.org (Ned Deily)
Date: Mon, 23 Feb 2009 14:28:30 -0800
Subject: [Pythonmac-SIG] Uninstalling Python 2.6?
References: <A9D9FD92-E516-4F6E-AD15-E367FB8DCB95@pixane.net>
	<dabdc63f0902230804w56b76207xe59c2dc9cad7b2fa@mail.gmail.com>
Message-ID: <nad-6084E8.14283023022009@news.gmane.org>

In article 
<dabdc63f0902230804w56b76207xe59c2dc9cad7b2fa at mail.gmail.com>,
 Orestis Markou <orestis at orestis.gr> wrote:
> I'm not on my Mac right now, but I think that the system python is
> actually in /System/Library rather than in /Library. If that's the
> case, I think you can just remove /Library/Frameworks/Python and
> update /usr/bin/python to point to vanilla Python.

/usr/bin/python normally always points to the Apple-supplied python in 
/System/Library; it's not a good idea to modify it.

> I would try renaming /Library/Frameworks/Python.framework and see if
> this fixes your issues - if yes, you can then safely delete it.
> 
> I personally use MacPorts, that installs itself in /opt/local and only
> fiddles with PATH, to avoid this kind of problem.

The python.org pythons install to 
/Library/Frameworks/Python.frameworks/Versions/x.x and to 
/Applications/Python x.x, neither of which are Apple-controlled 
locations.  The framework is totally self-contained unless you select to 
have the installer add symlinks to /usr/local/bin and, again, those are 
not Apple-controlled.  So you can safely delete the versioned framework 
directory and/or application directory or just alter your PATH to avoid 
them.   In *that* respect, there is no advantage to using MacPorts over 
python.org pythons.

-- 
 Ned Deily,
 nad at acm.org