From wrw at mac.com  Tue Oct  2 22:34:54 2012
From: wrw at mac.com (wrw at mac.com)
Date: Tue, 02 Oct 2012 16:34:54 -0400
Subject: [Pythonmac-SIG] Tkinter ttk question
Message-ID: <E3BFE80B-1860-4C81-9DE8-E2DAB3E5F8B4@mac.com>

This may or may not be the best place to ask this, but here goes:

I'm exploring different GUI packages for python programs I'm writing.  I've played a bit with wx and now am exploring Tkinter and ttk 8.5 following the tutorial at http://www.tkdocs.com/tutorial.

The first example program is pasted in below:

#!/usr/bin/env python
from Tkinter import *
import ttk

def calculate(*args):
    try:
        value = float(feet.get())
        meters.set((0.3048 * value * 10000.0 + 0.5)/10000.0)
    except ValueError:
        pass
    
root = Tk()
root.title("Feet to Meters")

mainframe = ttk.Frame(root, padding="5 5 5 5")  # padding order: West, Top, East, South
mainframe.grid(column=0, row=0, sticky=(N, W, E, S))
mainframe.columnconfigure(0, weight=1)
mainframe.rowconfigure(0, weight=1)
feet = StringVar()
meters = StringVar()
feet_entry = ttk.Entry(mainframe, textvariable=feet, width=9)
feet_entry.grid(column=2, row=1, sticky=(W, E))
meters_entry = ttk.Entry(mainframe, textvariable=meters, width = 9)
meters_entry.grid(column = 2, row = 2, sticky =(W, E))
ttk.Button(mainframe, text="Calculate", command=calculate, default = "active").grid(column=3, row=3, sticky=W)
ttk.Label(mainframe, text="feet").grid(column=3, row=1, sticky=W)
ttk.Label(mainframe, text="is equivalent to").grid(column=1, row=2, sticky=E)
ttk.Label(mainframe, text="meters").grid(column=3, row=2, sticky=W)

for child in mainframe.winfo_children(): child.grid_configure(padx=5, pady=5)

feet_entry.focus()
root.bind('<Return>', calculate)

root.mainloop()


Quoting from the explanation:
Next, we create a frame widget, which will hold all the content of our user interface, and place that in our main window. The"columnconfigure"/"rowconfigure" bits just tell Tk that if the main window is resized, the frame should expand to take up the extra space.

The problem I'm having is that this doesn't work.  If I resize the window, the light gray background doesn't expand with the root window.  I get a light gray patch the size of the original frame, but it is surrounded by white space.  Can anyone tell me what I'm doing wrong.

64-bit Python 2.7 from python.org and I believe, but can't confirm, that Tkinter and ttk are from Active State.
Mac OS X 10.8.2, 2 x Quad processor Intel Xeon. 

As an additional query, is there another source for Tkinter and ttk?

Thanks in advance,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20121002/86c82edb/attachment.html>

From kw at codebykevin.com  Wed Oct  3 02:35:19 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 02 Oct 2012 20:35:19 -0400
Subject: [Pythonmac-SIG] Tkinter ttk question
In-Reply-To: <E3BFE80B-1860-4C81-9DE8-E2DAB3E5F8B4@mac.com>
References: <E3BFE80B-1860-4C81-9DE8-E2DAB3E5F8B4@mac.com>
Message-ID: <506B8847.2040604@codebykevin.com>

On 10/2/12 4:34 PM, wrw at mac.com wrote:
> The problem I'm having is that this doesn't work.  If I resize the
> window, the light gray background doesn't expand with the root window.
>   I get a light gray patch the size of the original frame, but it is
> surrounded by white space.  Can anyone tell me what I'm doing wrong.

I prefer pack to grid. Try this:

mainframe.pack(fill=BOTH, expand=YES)

--Kevin

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

From wrw at mac.com  Wed Oct  3 03:00:58 2012
From: wrw at mac.com (wrw at mac.com)
Date: Tue, 02 Oct 2012 21:00:58 -0400
Subject: [Pythonmac-SIG] Tkinter ttk question
In-Reply-To: <506B8847.2040604@codebykevin.com>
References: <E3BFE80B-1860-4C81-9DE8-E2DAB3E5F8B4@mac.com>
	<506B8847.2040604@codebykevin.com>
Message-ID: <1D89FFA4-BA6D-4698-97E1-44E8ADF1BE73@mac.com>

On Oct 2, 2012, at 8:35 PM, Kevin Walzer <kw at codebykevin.com> wrote:

> On 10/2/12 4:34 PM, wrw at mac.com wrote:
>> The problem I'm having is that this doesn't work.  If I resize the
>> window, the light gray background doesn't expand with the root window.
>>  I get a light gray patch the size of the original frame, but it is
>> surrounded by white space.  Can anyone tell me what I'm doing wrong.
> 
> I prefer pack to grid. Try this:
> 
> mainframe.pack(fill=BOTH, expand=YES)
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

That worked.  Thanks.  Bill

From scottclausen at mac.com  Mon Oct  8 09:46:39 2012
From: scottclausen at mac.com (Scott Clausen)
Date: Mon, 08 Oct 2012 00:46:39 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python 3.3
	on OSX 10.8.2
Message-ID: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>

Whenever I attempt to access the IDLE prefs the app crashes. I want to be able to enlarge the text for my old eyes.

I've looked on the python website with no luck and have removed the current Python file and reinstalled with no luck I'm using the Tk/Tcl that comes with the OS, I believe. Could their be a need for an update that I'm not aware of?

Thanks,

Scott

--- People are taking their comedians seriously and their politicians as a joke.

? Will Rogers


From kw at codebykevin.com  Mon Oct  8 12:28:12 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 08 Oct 2012 06:28:12 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
Message-ID: <5072AABC.8050308@codebykevin.com>

On 10/8/12 3:46 AM, Scott Clausen wrote:
> Could their be a need for an update that I'm not aware of?

Yes, probably--there was a crash in Tk 8.5.12 that has since been fixed, 
but a binary release from ActiveState has not yet been made. When they 
release a new version the crash should go away.

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

From nad at acm.org  Mon Oct  8 22:22:45 2012
From: nad at acm.org (Ned Deily)
Date: Mon, 08 Oct 2012 13:22:45 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
	3.3 on OSX 10.8.2
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
Message-ID: <nad-FABD2C.13224508102012@news.gmane.org>

In article <5072AABC.8050308 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:
> On 10/8/12 3:46 AM, Scott Clausen wrote:
> > Could their be a need for an update that I'm not aware of?
> 
> Yes, probably--there was a crash in Tk 8.5.12 that has since been fixed, 
> but a binary release from ActiveState has not yet been made. When they 
> release a new version the crash should go away.

It has not been fixed yet.  The workaround at the moment is to revert to 
an older version of ActiveState, 8.5.11.1, as described here:

http://www.python.org/download/mac/tcltk/

-- 
 Ned Deily,
 nad at acm.org


From kw at codebykevin.com  Mon Oct  8 23:23:20 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 08 Oct 2012 17:23:20 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-FABD2C.13224508102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
Message-ID: <50734448.30202@codebykevin.com>

On 10/8/12 4:22 PM, Ned Deily wrote:
> It has not been fixed yet.

Is this statement based on a fresh checkout of the core-8-5-branch from 
http://core.tcl.tk/tk? Because my build of 8.5 dates from about a week 
ago, and the preferences menu issue is fixed.

What I said before holds: the fix is now in the source tree, but 
ActiveState has not yet released an updated build of ActiveTcl to 
include the fix. The OP can certainly download and build the Tcl/Tk 
sources himself to get the fix; I agree that an alternative workaround 
would be to revert to an older build of ActiveTcl, assuming it's still 
available.

--Kevin

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

From nad at acm.org  Mon Oct  8 23:34:55 2012
From: nad at acm.org (Ned Deily)
Date: Mon, 08 Oct 2012 14:34:55 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
	3.3 on OSX 10.8.2
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
Message-ID: <nad-10D24D.14345508102012@news.gmane.org>

In article <50734448.30202 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:
> On 10/8/12 4:22 PM, Ned Deily wrote:
> > It has not been fixed yet.
> 
> Is this statement based on a fresh checkout of the core-8-5-branch from 
> http://core.tcl.tk/tk? Because my build of 8.5 dates from about a week 
> ago, and the preferences menu issue is fixed.
> 
> What I said before holds: the fix is now in the source tree, but 
> ActiveState has not yet released an updated build of ActiveTcl to 
> include the fix. The OP can certainly download and build the Tcl/Tk 
> sources himself to get the fix; I agree that an alternative workaround 
> would be to revert to an older build of ActiveTcl, assuming it's still 
> available.

As far as I can tell, the problem is not fixed in the source tree.  The 
problem is trivial to reproduce with Python and IDLE.  Try it with your 
own build of Tk 8.5 installed in /Library/Frameworks and with any of the 
current python.org 64-bit/32-bit installers 
(http://www.python.org/download/) or with the ActiveState Python 
installers.  Launch the appropriate IDLE.app and select Preferences from 
the IDLE menu.

-- 
 Ned Deily,
 nad at acm.org


From kw at codebykevin.com  Tue Oct  9 01:01:48 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 08 Oct 2012 19:01:48 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-10D24D.14345508102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
Message-ID: <50735B5C.6040507@codebykevin.com>

On 10/8/12 5:34 PM, Ned Deily wrote:
> As far as I can tell, the problem is not fixed in the source tree.  The
> problem is trivial to reproduce with Python and IDLE.  Try it with your
> own build of Tk 8.5 installed in /Library/Frameworks and with any of the
> current python.org 64-bit/32-bit installers
> (http://www.python.org/download/) or with the ActiveState Python
> installers.  Launch the appropriate IDLE.app and select Preferences from
> the IDLE menu.

I moved my own build of Python out of the way, and installed 
ActivePython 2.7.2, which links against my custom build of Tcl/Tk in 
/Library/Frameworks, based on a week-old checkout of the tip of the 
core-8-5-branch. Launching IDLE and typing Command-, brings up the 
preferences dialog without any crash.

Again, I'm not sure what version of Tk you are testing against? If 
you're testing against the most recent build of ActiveTcl, you won't see 
this fix, because ActiveState hasn't incorporated it yet. The fix was 
committed in the past month or so, I believe, as part of the input 
method patch submitted by Adrian Robert.

--Kevin

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

From kw at codebykevin.com  Tue Oct  9 03:06:31 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 08 Oct 2012 21:06:31 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-10D24D.14345508102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
Message-ID: <50737897.9030803@codebykevin.com>

On 10/8/12 5:34 PM, Ned Deily wrote:
> As far as I can tell, the problem is not fixed in the source tree.  The
> problem is trivial to reproduce with Python and IDLE.  Try it with your
> own build of Tk 8.5 installed in /Library/Frameworks and with any of the
> current python.org 64-bit/32-bit installers
> (http://www.python.org/download/) or with the ActiveState Python
> installers.  Launch the appropriate IDLE.app and select Preferences from
> the IDLE menu.

I've done some further testing of this, and have run into something very 
odd.

Just to be sure, I did a fresh checkout of Tk's core-8-5-branch and 
rebuilt it, and then rebuilt my installation of Python to link to it. 
(My recent Python apps have been linking to the Tk in 
/System/Library/Frameworks because of the Mac App Store, but as I'm 
moving away from the App Store that's no longer necessary.)

After rebuilding and re-linking everything, I can indeed confirm the 
crash in IDLE. Running Command-, causes the app to crash instead of 
bringing up the preferences menu. However, I can't reproduce the crash 
in Tk itself. Running Wish, I define the standard 
tk::mac::ShowPrefrences procedure to print "foo" to standard output, and 
it works as expected. This is why I said I didn't see the error and 
wondered what version of Tk you were testing.

What happens if something crashes in Tkinter but not in Tk directly? Is 
this considered a bug in Python/Tkinter? Because IDLE's preferences 
method is calling into tk::mac::ShowPreferences, then it shouldn't crash 
unless Wish is also crashing. I don't know what to say if something 
crashes in Python/Tkinter but not in Tk.

--Kevin

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

From nad at acm.org  Tue Oct  9 11:26:14 2012
From: nad at acm.org (Ned Deily)
Date: Tue, 09 Oct 2012 02:26:14 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
	3.3 on OSX 10.8.2
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
Message-ID: <nad-FD9C38.02261409102012@news.gmane.org>

In article <50737897.9030803 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:
> On 10/8/12 5:34 PM, Ned Deily wrote:
> > As far as I can tell, the problem is not fixed in the source tree.  The
> > problem is trivial to reproduce with Python and IDLE.  Try it with your
> > own build of Tk 8.5 installed in /Library/Frameworks and with any of the
> > current python.org 64-bit/32-bit installers
> > (http://www.python.org/download/) or with the ActiveState Python
> > installers.  Launch the appropriate IDLE.app and select Preferences from
> > the IDLE menu.
> I've done some further testing of this, and have run into something very 
> odd.
> 
> Just to be sure, I did a fresh checkout of Tk's core-8-5-branch and 
> rebuilt it, and then rebuilt my installation of Python to link to it. 
> (My recent Python apps have been linking to the Tk in 
> /System/Library/Frameworks because of the Mac App Store, but as I'm 
> moving away from the App Store that's no longer necessary.)
> 
> After rebuilding and re-linking everything, I can indeed confirm the 
> crash in IDLE. Running Command-, causes the app to crash instead of 
> bringing up the preferences menu. However, I can't reproduce the crash 
> in Tk itself. Running Wish, I define the standard 
> tk::mac::ShowPrefrences procedure to print "foo" to standard output, and 
> it works as expected. This is why I said I didn't see the error and 
> wondered what version of Tk you were testing.

I've done some extensive building and bisecting of Fossil checkins to 
the tk-cocoa-8-5-backport branch and have isolated the regression to a 
particular checkin.  I've opened Tk issue 3575664 with the details and 
provided a debug crash dump.

https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&grou
p_id=12997

BTW, I've also opened Tk issue 3575681 to document that the earlier 
clipboard copy crash regression can still be reproduced with IDLE.

-- 
 Ned Deily,
 nad at acm.org


From kw at codebykevin.com  Wed Oct 10 05:28:24 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 09 Oct 2012 23:28:24 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-FD9C38.02261409102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
Message-ID: <5074EB58.5090201@codebykevin.com>

On 10/9/12 5:26 AM, Ned Deily wrote:
> I've done some extensive building and bisecting of Fossil checkins to
> the tk-cocoa-8-5-backport branch and have isolated the regression to a
> particular checkin.  I've opened Tk issue 3575664 with the details and
> provided a debug crash dump.

I've done some additional testing of this in Tk, and cannot reproduce 
the crash. Also, this sample Tkinter script runs without any crash:

#######
from Tkinter import *

root = Tk()

w = Label(root, text="Hello, world!")
w.pack()

def showPreferences():
     top = Toplevel()
     top.title("About this application...")

root.createcommand('::tk::mac::ShowPreferences', showPreferences)
root.mainloop()
########

I think the culprit is somewhere in IDLE's internals, but I can't be 
sure. If the bug is in Tkinter's internals, this script should crash, 
but it doesn't. Please try it to confirm.

At this point I'm not sure what else to suggest.

--Kevin

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

From kw at codebykevin.com  Wed Oct 10 05:32:46 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Tue, 09 Oct 2012 23:32:46 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <5074EB58.5090201@codebykevin.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
Message-ID: <5074EC5E.2090502@codebykevin.com>

P.S. To fire the prefs dialog, type Command-, or command-comma. That is 
the default keybinding even though I did not explicitly enable it in the 
script.

From ronaldoussoren at mac.com  Wed Oct 10 16:19:16 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 10 Oct 2012 16:19:16 +0200
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <5074EB58.5090201@codebykevin.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
Message-ID: <CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>


On 10 Oct, 2012, at 5:28, Kevin Walzer <kw at codebykevin.com> wrote:

> On 10/9/12 5:26 AM, Ned Deily wrote:
>> I've done some extensive building and bisecting of Fossil checkins to
>> the tk-cocoa-8-5-backport branch and have isolated the regression to a
>> particular checkin.  I've opened Tk issue 3575664 with the details and
>> provided a debug crash dump.
> 
> I've done some additional testing of this in Tk, and cannot reproduce the crash. Also, this sample Tkinter script runs without any crash:
> 
> #######
> from Tkinter import *
> 
> root = Tk()
> 
> w = Label(root, text="Hello, world!")
> w.pack()
> 
> def showPreferences():
>    top = Toplevel()
>    top.title("About this application...")
> 
> root.createcommand('::tk::mac::ShowPreferences', showPreferences)
> root.mainloop()
> ########
> 
> I think the culprit is somewhere in IDLE's internals, but I can't be sure. If the bug is in Tkinter's internals, this script should crash, but it doesn't. Please try it to confirm.

That odd.  IDLE also uses '::tk::mac::ShowPreferences' for the configuration dialog. The only difference with your script is that the same command is also bound to '<<open-config-dialog>>'.  The code for this all is in idlelib.macosxSupport.overrideRootMenu in the stdlib.

Ronald



> 
> At this point I'm not sure what else to suggest.
> 
> --Kevin
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


From kw at codebykevin.com  Thu Oct 11 01:19:30 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 10 Oct 2012 19:19:30 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
Message-ID: <50760282.1040208@codebykevin.com>

On 10/10/12 10:19 AM, Ronald Oussoren wrote:
> That odd.  IDLE also uses '::tk::mac::ShowPreferences' for the configuration dialog. The only difference with your script is that the same command is also bound to '<<open-config-dialog>>'.  The code for this all is in idlelib.macosxSupport.overrideRootMenu in the stdlib.

Indeed it's strange. The stack trace suggests the problem is coming from 
Tk, but I cannot reproduce the issue in Tk nor can I reproduce it with 
the simple sample Python script. As a result I am not sure what to do here.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   Tk                            	0x0b0c2079 0xb000000 + 794745
1   Tk                            	0x0b03e03d 0xb000000 + 254013
2   Tk                            	0x0b0159e0 0xb000000 + 88544
3   Tk                            	0x0b0159ec 0xb000000 + 88556
4   Tk                            	0x0b0159ec 0xb000000 + 88556
5   Tcl                           	0x0a0990fa TclServiceIdle + 63
6   Tcl                           	0x0a07c2f2 Tcl_DoOneEvent + 213
7   Tk                            	0x0b0386ab 0xb000000 + 231083
8   Tcl                           	0x0a0990fa TclServiceIdle + 63
9   Tcl                           	0x0a07c2f2 Tcl_DoOneEvent + 213
10  Tk                            	0x0b00e59e 0xb000000 + 58782
11  Tcl                           	0x0a00d4bb 0xa000000 + 54459
12  Tcl                           	0x0a00e448 Tcl_EvalObjv + 66
13  _tkinter.so                   	0x00591b45 Tkapp_Call + 725 
(_tkinter.c:1379)
14  org.python.python             	0x0004acbc PyCFunction_Call + 92
15  org.python.python             	0x000a2bcd PyEval_EvalFrameEx + 15277
16  org.python.python             	0x000a585d PyEval_EvalCodeEx + 1885
17  org.python.python             	0x000a5a19 fast_function + 297
18  org.python.python             	0x000a2c6d PyEval_EvalFrameEx + 15437
19  org.python.python             	0x000a585d PyEval_EvalCodeEx + 1885
20  org.python.python             	0x00035b5b function_call + 331
21  org.python.python             	0x0000cad1 PyObject_Call + 97
22  org.python.python             	0x0001e80e instancemethod_call + 462
23  org.python.python             	0x0000cad1 PyObject_Call + 97
24  org.python.python             	0x0009e47e 
PyEval_CallObjectWithKeywords + 174
25  org.python.python             	0x0001a837 PyInstance_New + 295
26  org.python.python             	0x0000cad1 PyObject_Call + 97
27  org.python.python             	0x000a2e79 PyEval_EvalFrameEx + 15961
28  org.python.python             	0x000a585d PyEval_EvalCodeEx + 1885
29  org.python.python             	0x00035b5b function_call + 331
30  org.python.python             	0x0000cad1 PyObject_Call + 97
31  org.python.python             	0x0009e47e 
PyEval_CallObjectWithKeywords + 174
32  _tkinter.so                   	0x00595820 PythonCmd + 224 
(_tkinter.c:2074)
33  Tcl                           	0x0a00b6d5 TclInvokeStringCommand + 110
34  Tcl                           	0x0a00d4bb 0xa000000 + 54459
35  Tcl                           	0x0a00dfb3 0xa000000 + 57267
36  Tcl                           	0x0a00e334 Tcl_GlobalEval + 72
37  Tk                            	0x0b0bc7d8 0xb000000 + 772056
38  Tk                            	0x0b0bc817 0xb000000 + 772119
39  com.apple.CoreFoundation      	0x97f8cd11 -[NSObject 
performSelector:withObject:] + 65
40  com.apple.AppKit              	0x95a79663 -[NSApplication 
sendAction:to:from:] + 232
41  com.apple.AppKit              	0x95cb3968 -[NSCarbonMenuImpl 
performMenuAction:withTarget:] + 247
42  com.apple.AppKit              	0x95ae61e9 -[NSMenu 
_performKeyEquivalentWithDelegate:] + 374
43  com.apple.AppKit              	0x95ae6325 -[NSMenu 
_performKeyEquivalentWithDelegate:] + 690
44  com.apple.AppKit              	0x95ae5d94 -[NSMenu 
performKeyEquivalent:] + 79
45  com.apple.AppKit              	0x95ae48e6 -[NSApplication 
_handleKeyEquivalent:] + 594
46  com.apple.AppKit              	0x959da34f -[NSApplication 
sendEvent:] + 5772
47  Tk                            	0x0b0c591e 0xb000000 + 809246
48  Tk                            	0x0b0c5ca6 0xb000000 + 810150
49  Tcl                           	0x0a07c2d1 Tcl_DoOneEvent + 180
50  _tkinter.so                   	0x00593ef3 Tkapp_MainLoop + 355 
(_tkinter.c:2638)

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

From nad at acm.org  Thu Oct 11 01:38:10 2012
From: nad at acm.org (Ned Deily)
Date: Wed, 10 Oct 2012 16:38:10 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
	3.3 on OSX 10.8.2
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
Message-ID: <nad-00AC8B.16381010102012@news.gmane.org>

In article <50760282.1040208 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:

> On 10/10/12 10:19 AM, Ronald Oussoren wrote:
> > That odd.  IDLE also uses '::tk::mac::ShowPreferences' for the 
> > configuration dialog. The only difference with your script is that the same 
> > command is also bound to '<<open-config-dialog>>'.  The code for this all 
> > is in idlelib.macosxSupport.overrideRootMenu in the stdlib.
> 
> Indeed it's strange. The stack trace suggests the problem is coming from 
> Tk, but I cannot reproduce the issue in Tk nor can I reproduce it with 
> the simple sample Python script. As a result I am not sure what to do here.

Look at the dump file I attached to the Tk issue.  It has a complete 
debug trace through Tk including C line numbers.

http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&group
_id=12997

-- 
 Ned Deily,
 nad at acm.org


From kw at codebykevin.com  Thu Oct 11 02:04:55 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 10 Oct 2012 20:04:55 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-00AC8B.16381010102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
Message-ID: <50760D27.50202@codebykevin.com>

On 10/10/12 7:38 PM, Ned Deily wrote:
> Look at the dump file I attached to the Tk issue.  It has a complete
> debug trace through Tk including C line numbers.

My stack trace is completely different, so I'm not sure where to look.

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

From kw at codebykevin.com  Thu Oct 11 04:02:04 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 10 Oct 2012 22:02:04 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-00AC8B.16381010102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
Message-ID: <5076289C.7060406@codebykevin.com>

On 10/10/12 7:38 PM, Ned Deily wrote:
> Look at the dump file I attached to the Tk issue.  It has a complete
> debug trace through Tk including C line numbers.
>
> http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&group
> _id=12997

I've been stepping through the IDLE source code and it appears IDLE is 
crashing during the LoadConfigs() call of the config dialog. Still have 
more investigating to do, but I'm hopeful I can come up with a 
workaround that will keep things from crashing.

The stack trace that I posted earlier, in my own testing, indicates that 
the issue may be during the infernal event loop integration between Tk 
and Cocoa--there's been a lot of traffic on the Mac-Tcl list about that. 
Fortunately, while the low-level event loop issues are more or less 
unavoidable at this time, they can often be worked around at the script 
level with calls to update, after idle, etc. It may take some trial and 
error here to get that working.
If I'm successful, where should I submit a patch?

--Kevin

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

From kw at codebykevin.com  Thu Oct 11 05:26:02 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 10 Oct 2012 23:26:02 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <5076289C.7060406@codebykevin.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
	<5076289C.7060406@codebykevin.com>
Message-ID: <50763C4A.9040309@codebykevin.com>

On 10/10/12 10:02 PM, Kevin Walzer wrote:
> I've been stepping through the IDLE source code and it appears IDLE is
> crashing during the LoadConfigs() call of the config dialog. Still have
> more investigating to do, but I'm hopeful I can come up with a
> workaround that will keep things from crashing.

I've traced the crash to this call in configDialog.py, around line 830 
or so:

def SetFontSample(self,event=None):
        fontName=self.fontName.get()
        if self.fontBold.get():
            fontWeight=tkFont.BOLD
        else:
            fontWeight=tkFont.NORMAL
        ###This is where it crashes!! How to fix?
        self.editFont.config(size=self.fontSize.get(),
                 weight=fontWeight,family=fontName)

Specifically, the crash occurs in self.editFont.config, which configures 
the font-sample display in the preferences dialog. I haven't been able 
to develop a workaround yet--calls to "self.update," etc. haven't 
worked--and will revisit it in the next day or so. Any other suggestions 
are appreciated.

--Kevin

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

From nad at acm.org  Thu Oct 11 05:26:03 2012
From: nad at acm.org (Ned Deily)
Date: Wed, 10 Oct 2012 20:26:03 -0700
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
	3.3 on OSX 10.8.2
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
	<5076289C.7060406@codebykevin.com>
Message-ID: <nad-016715.20260310102012@news.gmane.org>

In article <5076289C.7060406 at codebykevin.com>,
 Kevin Walzer <kw at codebykevin.com> wrote:
> The stack trace that I posted earlier, in my own testing, indicates that 
> the issue may be during the infernal event loop integration between Tk 
> and Cocoa--there's been a lot of traffic on the Mac-Tcl list about that. 
> Fortunately, while the low-level event loop issues are more or less 
> unavoidable at this time, they can often be worked around at the script 
> level with calls to update, after idle, etc. It may take some trial and 
> error here to get that working.
> If I'm successful, where should I submit a patch?

A Python patch could go here:
http://bugs.python.org/issue15853

-- 
 Ned Deily,
 nad at acm.org


From ronaldoussoren at mac.com  Thu Oct 11 12:23:11 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 11 Oct 2012 12:23:11 +0200
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <5076289C.7060406@codebykevin.com>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
	<5076289C.7060406@codebykevin.com>
Message-ID: <A64D0ABA-D309-4FE3-B3D0-654A08425616@mac.com>


On 11 Oct, 2012, at 4:02, Kevin Walzer <kw at codebykevin.com> wrote:

> On 10/10/12 7:38 PM, Ned Deily wrote:
>> Look at the dump file I attached to the Tk issue.  It has a complete
>> debug trace through Tk including C line numbers.
>> 
>> http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3575664&group
>> _id=12997
> 
> I've been stepping through the IDLE source code and it appears IDLE is crashing during the LoadConfigs() call of the config dialog. Still have more investigating to do, but I'm hopeful I can come up with a workaround that will keep things from crashing.
> 
> The stack trace that I posted earlier, in my own testing, indicates that the issue may be during the infernal event loop integration between Tk and Cocoa--there's been a lot of traffic on the Mac-Tcl list about that. Fortunately, while the low-level event loop issues are more or less unavoidable at this time, they can often be worked around at the script level with calls to update, after idle, etc. It may take some trial and error here to get that working.
> If I'm successful, where should I submit a patch?

The python tracker (http://bugs.python.org/)

Ronald


From kw at codebykevin.com  Fri Oct 12 05:09:20 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Thu, 11 Oct 2012 23:09:20 -0400
Subject: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python
 3.3 on OSX 10.8.2
In-Reply-To: <nad-016715.20260310102012@news.gmane.org>
References: <86EF1212-F3F4-47EE-8C4B-6C34550EAAAA@mac.com>
	<5072AABC.8050308@codebykevin.com>
	<nad-FABD2C.13224508102012@news.gmane.org>
	<50734448.30202@codebykevin.com>
	<nad-10D24D.14345508102012@news.gmane.org>
	<50737897.9030803@codebykevin.com>
	<nad-FD9C38.02261409102012@news.gmane.org>
	<5074EB58.5090201@codebykevin.com>
	<CFD7F7D7-6DB7-4F7D-AE8C-1F4EB603BB48@mac.com>
	<50760282.1040208@codebykevin.com>
	<nad-00AC8B.16381010102012@news.gmane.org>
	<5076289C.7060406@codebykevin.com>
	<nad-016715.20260310102012@news.gmane.org>
Message-ID: <507789E0.3050008@codebykevin.com>

On 10/10/12 11:26 PM, Ned Deily wrote:

>
> A Python patch could go here:
> http://bugs.python.org/issue15853
>

Patch submitted. The preferences dialog no longer crashes for me.

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

From chris.barker at noaa.gov  Tue Oct 16 01:24:52 2012
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 15 Oct 2012 16:24:52 -0700
Subject: [Pythonmac-SIG] permission of doc dir
Message-ID: <CALGmxEKcYW0Zk9QvqPjqVCFR=Gdb6rC4RNbSKgKMQ9Lr0XAxqA@mail.gmail.com>

Hi folks,

I just tried to "pip install ipython" and got:

error: could not create
'/Library/Frameworks/Python.framework/Versions/2.7/share/doc/ipython':
Permission denied

indeed:

$ ls -l /Library/Frameworks/Python.framework/Versions/2.7/share/
total 0
drwxr-xr-x  3 root  admin  102 Oct 11 09:14 doc
drwxrwxr-x  3 root  admin  102 Jun 11  2011 man

which looks like the doc dir should have the same perms as the man dir.

no biggie, I can fix that, but we might want to clen up that tiny
nugget in future builds.

( Python.org build for 32 bit 10.3+ )

-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 nad at acm.org  Tue Oct 16 02:13:29 2012
From: nad at acm.org (Ned Deily)
Date: Mon, 15 Oct 2012 17:13:29 -0700
Subject: [Pythonmac-SIG] permission of doc dir
References: <CALGmxEKcYW0Zk9QvqPjqVCFR=Gdb6rC4RNbSKgKMQ9Lr0XAxqA@mail.gmail.com>
Message-ID: <nad-6ED98D.17132915102012@news.gmane.org>

In article 
<CALGmxEKcYW0Zk9QvqPjqVCFR=Gdb6rC4RNbSKgKMQ9Lr0XAxqA at mail.gmail.com>,
 Chris Barker <chris.barker at noaa.gov> wrote:
> I just tried to "pip install ipython" and got:
> 
> error: could not create
> '/Library/Frameworks/Python.framework/Versions/2.7/share/doc/ipython':
> Permission denied
> 
> indeed:
> 
> $ ls -l /Library/Frameworks/Python.framework/Versions/2.7/share/
> total 0
> drwxr-xr-x  3 root  admin  102 Oct 11 09:14 doc
> drwxrwxr-x  3 root  admin  102 Jun 11  2011 man
> 
> which looks like the doc dir should have the same perms as the man dir.
> 
> no biggie, I can fix that, but we might want to clen up that tiny
> nugget in future builds.

Chris,

Please open an issue on the bug tracker so we don't forget.  Thanks!

-- 
 Ned Deily,
 nad at acm.org


From chris.barker at noaa.gov  Wed Oct 17 00:59:42 2012
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 16 Oct 2012 15:59:42 -0700
Subject: [Pythonmac-SIG] permission of doc dir
In-Reply-To: <8FD6A026-0766-4918-AD68-D0A37F5C1188@acm.org>
References: <CALGmxEKcYW0Zk9QvqPjqVCFR=Gdb6rC4RNbSKgKMQ9Lr0XAxqA@mail.gmail.com>
	<nad-6ED98D.17132915102012@news.gmane.org>
	<CALGmxELMfEfQBsA9TmtDQbRfdgUXO-gkC0wT+4+Xp-0k2hhERA@mail.gmail.com>
	<8FD6A026-0766-4918-AD68-D0A37F5C1188@acm.org>
Message-ID: <CALGmxELz_Sby5g-dNJUxqoAt0BoYKvo3svHgBCuuE7XvKmisTg@mail.gmail.com>

On Tue, Oct 16, 2012 at 3:16 PM, Ned Deily <nad at acm.org> wrote:

>> which bug tracker? The main python.org one?
>
> Yes, please.

will do.

> I've done an extensive update for the recently released 3.3 version.  I intend to backport some of the README and some of the Xcode 4 support, at least, to 2.7 before the next maintenance release, which should be coming up soon.  Lots to do!

great!, thanks for al your work on this.

-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  Wed Oct 17 00:58:22 2012
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 16 Oct 2012 15:58:22 -0700
Subject: [Pythonmac-SIG] Building a 32 bit framework build in a 64 bit system
Message-ID: <CALGmxE+tAoZmL2FTP8B6aO9GRLyFGkAOZGC4ODV8cEEXDd8dGw@mail.gmail.com>

Hi Folks,

I'm finding it a pain to force the Universal Python to 32 bit -- for
building extensions, as well as running, etc. So I though maybe it
would be nice to have a just plain 32 bit Intel build -- then I can
use that to run and test all mystuff (I'm depending on 32 bit only C++
code extensions), and also have something to re-distribute that
doesn't carry around worthless (for my needs)  64 bit baggage.

Poking through the READMEs, I'm having trouble figuring out how to
build a 32bit-only python framework on a 64 bit system.
--with-universal-archs values all have multiple builds (hence
universal...).

or is it as simple as passing arch=i386 in to configure?

(I'll want to build a dmg installer too, but cross that bridge when I
come to it...)

NOTE: I'm running 10.7, and would like to use the latest XCode (4.2?),
and am OK with the result only working on 10.7+ systems, though 10.6
and above would be nice.

-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  Wed Oct 17 01:10:33 2012
From: chris.barker at noaa.gov (Chris Barker)
Date: Tue, 16 Oct 2012 16:10:33 -0700
Subject: [Pythonmac-SIG] permission of doc dir
In-Reply-To: <nad-6ED98D.17132915102012@news.gmane.org>
References: <CALGmxEKcYW0Zk9QvqPjqVCFR=Gdb6rC4RNbSKgKMQ9Lr0XAxqA@mail.gmail.com>
	<nad-6ED98D.17132915102012@news.gmane.org>
Message-ID: <CALGmxE+jEiQb3HWgVRHcsWtJX8QyKs=zSooaUgWuTwv_HXYg=A@mail.gmail.com>

On Mon, Oct 15, 2012 at 5:13 PM, Ned Deily <nad at acm.org> wrote:
> Please open an issue on the bug tracker so we don't forget.  Thanks!

Done:

http://bugs.python.org/issue16256

-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 nad at acm.org  Wed Oct 17 07:48:13 2012
From: nad at acm.org (Ned Deily)
Date: Tue, 16 Oct 2012 22:48:13 -0700
Subject: [Pythonmac-SIG] Building a 32 bit framework build in a 64 bit
	system
References: <CALGmxE+tAoZmL2FTP8B6aO9GRLyFGkAOZGC4ODV8cEEXDd8dGw@mail.gmail.com>
Message-ID: <nad-C653E4.22481316102012@news.gmane.org>

In article 
<CALGmxE+tAoZmL2FTP8B6aO9GRLyFGkAOZGC4ODV8cEEXDd8dGw at mail.gmail.com>,
 Chris Barker <chris.barker at noaa.gov> wrote:
> I'm finding it a pain to force the Universal Python to 32 bit -- for
> building extensions, as well as running, etc. So I though maybe it
> would be nice to have a just plain 32 bit Intel build -- then I can
> use that to run and test all mystuff (I'm depending on 32 bit only C++
> code extensions), and also have something to re-distribute that
> doesn't carry around worthless (for my needs)  64 bit baggage.

With reasonably current python.org Pythons, you can use the ARCHFLAGS 
environment variable to limit which archs are used by Distutils (and 
tools which use Distutils like easy_install or pip) to build C extension 
modules.  For example, to limit to just 32-bit Intel, you could use 
something like:

    ARCHFLAGS='-arch i386' easy_install psutil

or 
    export ARCHFLAGS='-arch i386'
    python2.7-32 setup.py install

> Poking through the READMEs, I'm having trouble figuring out how to
> build a 32bit-only python framework on a 64 bit system.
> --with-universal-archs values all have multiple builds (hence
> universal...).

The Mac/README was revised and updated for the recent 3.3.0 release; at 
the moment, it has the most recent information.  While it was written 
for that release, most of the information applies to 2.7.x as well.

http://hg.python.org/cpython/file/default/Mac/README

> or is it as simple as passing arch=i386 in to configure?

Pretty much.   Here's a very simple configure for use with Xcode 4 and 
OS X 10.8 for a non-framework 32-bit-only build.   Adjust the deployment 
target as needed and for Xcode 3 I'd recommend using CC=gcc-4.2.

   ./configure CFLAGS="-arch i386" LDFLAGS="-arch i386" \
        CC=clang MACOSX_DEPLOYMENT_TARGET=10.8
 
> (I'll want to build a dmg installer too, but cross that bridge when I
> come to it...)

Look at the readme for the installer build script (again, this is the 
more recent 3.3+ version):

http://hg.python.org/cpython/file/default/Mac/BuildScript/README.txt
 
> NOTE: I'm running 10.7, and would like to use the latest XCode (4.2?),
> and am OK with the result only working on 10.7+ systems, though 10.6
> and above would be nice.

Set the deployment target env variable to 10.6 or whatever version you 
need.  By the way, at the moment, the latest version of Xcode for 10.7 
and 10.8 is Xcode 4.5.1 available for free through App Store.app.

There are some gotchas with the most recent versions of Xcode 4.  Among 
them are the elimination of the use of the /Developer directory; now 
things like SDKs are contained within Xcode.app itself.  You can find 
them using xcodebuild:

    xcodebuild -version -sdk macosx10.7 Path
    
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve
loper/SDKs/MacOSX10.7.sdk

And, after installing/updating Xcode.app, you also need to install the 
"Command Line Tools" component of Xcode from Xcode -> Preferences.  That 
installs things like clang, make, ld, and system include files into 
their conventional places within /usr.

Good luck!

-- 
 Ned Deily,
 nad at acm.org


From emanuelesantos at gmail.com  Wed Oct 17 16:12:54 2012
From: emanuelesantos at gmail.com (Emanuele Santos)
Date: Wed, 17 Oct 2012 11:12:54 -0300
Subject: [Pythonmac-SIG] Building an extensible bundle with py2app
Message-ID: <CACTfVWT6dNRt6+6hPTAyHJzxrt6tGePPLXbgrY+zh7dCoqSSyQ@mail.gmail.com>

Hi, all

We build a bundle with py2app and we would like to make it extensible so
users could install on demand other python packages into the python
framework included in the bundle, for example by running easy_install.

Is there a recommended way of doing that? I noticed that the site.py file
included in the bundle is not complete so when I tried using the --user
command line option or setting the $PYTHONHOME, I got an error.

Thanks,

-- Emanuele.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20121017/61c74585/attachment.html>

From ronaldoussoren at mac.com  Wed Oct 17 16:45:24 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 17 Oct 2012 16:45:24 +0200
Subject: [Pythonmac-SIG] Building an extensible bundle with py2app
In-Reply-To: <CACTfVWT6dNRt6+6hPTAyHJzxrt6tGePPLXbgrY+zh7dCoqSSyQ@mail.gmail.com>
References: <CACTfVWT6dNRt6+6hPTAyHJzxrt6tGePPLXbgrY+zh7dCoqSSyQ@mail.gmail.com>
Message-ID: <2C2A1F22-59B4-4FFE-8B58-E66D2FB0EAF7@mac.com>


On 17 Oct, 2012, at 16:12, Emanuele Santos <emanuelesantos at gmail.com> wrote:

> Hi, all
> 
> We build a bundle with py2app and we would like to make it extensible so users could install on demand other python packages into the python framework included in the bundle, for example by running easy_install.
> 
> Is there a recommended way of doing that? I noticed that the site.py file included in the bundle is not complete so when I tried using the --user command line option or setting the $PYTHONHOME, I got an error.

I wouldn't change the application bundle itself, but would add an option to load python code from a user specified location. There are two reasons for not changing the application bundle itself: that would invalidate code signatures, and users cannot necessarily write into the bundle (I tend to install applications using a separate account with more privileges than my normal account).

One way to do this is adding something like this to your application's startup code:

    import os
    import site

    site.addsitedir(os.path.expanduser("~/Library/Application Support/MyApp/Python"))

Users can then install additional modules in "~/Library/Application Support/MyApp/Python" and your application can then use them.

If you're using a semi-standalone build (for example because you use Apple's python build) you can also use the "--site-packages" option to add the default site-packages directory to your application's search path. However, when I look at the code that not only just works for semi-standalone builds, but I'm also also not sure if the code that adds ~/Library/Python/... to sys.path actually works.

Ronald
> 
> Thanks,
> 
> -- Emanuele.
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


From chris.barker at noaa.gov  Wed Oct 17 20:38:11 2012
From: chris.barker at noaa.gov (Chris Barker)
Date: Wed, 17 Oct 2012 11:38:11 -0700
Subject: [Pythonmac-SIG] Building a 32 bit framework build in a 64 bit
	system
In-Reply-To: <nad-C653E4.22481316102012@news.gmane.org>
References: <CALGmxE+tAoZmL2FTP8B6aO9GRLyFGkAOZGC4ODV8cEEXDd8dGw@mail.gmail.com>
	<nad-C653E4.22481316102012@news.gmane.org>
Message-ID: <CALGmxE+HWesgrdn0+rUOfMfH6SP8eBHzQCoVM02QTSWTORqj-g@mail.gmail.com>

Ned,

Thanks for the detailed reply -- not sure when I'll be able to really
try this, but I'll let this list know how it goes when I do.

-CHB


On Tue, Oct 16, 2012 at 10:48 PM, Ned Deily <nad at acm.org> wrote:
> In article
> <CALGmxE+tAoZmL2FTP8B6aO9GRLyFGkAOZGC4ODV8cEEXDd8dGw at mail.gmail.com>,
>  Chris Barker <chris.barker at noaa.gov> wrote:
>> I'm finding it a pain to force the Universal Python to 32 bit -- for
>> building extensions, as well as running, etc. So I though maybe it
>> would be nice to have a just plain 32 bit Intel build -- then I can
>> use that to run and test all mystuff (I'm depending on 32 bit only C++
>> code extensions), and also have something to re-distribute that
>> doesn't carry around worthless (for my needs)  64 bit baggage.
>
> With reasonably current python.org Pythons, you can use the ARCHFLAGS
> environment variable to limit which archs are used by Distutils (and
> tools which use Distutils like easy_install or pip) to build C extension
> modules.  For example, to limit to just 32-bit Intel, you could use
> something like:
>
>     ARCHFLAGS='-arch i386' easy_install psutil
>
> or
>     export ARCHFLAGS='-arch i386'
>     python2.7-32 setup.py install
>
>> Poking through the READMEs, I'm having trouble figuring out how to
>> build a 32bit-only python framework on a 64 bit system.
>> --with-universal-archs values all have multiple builds (hence
>> universal...).
>
> The Mac/README was revised and updated for the recent 3.3.0 release; at
> the moment, it has the most recent information.  While it was written
> for that release, most of the information applies to 2.7.x as well.
>
> http://hg.python.org/cpython/file/default/Mac/README
>
>> or is it as simple as passing arch=i386 in to configure?
>
> Pretty much.   Here's a very simple configure for use with Xcode 4 and
> OS X 10.8 for a non-framework 32-bit-only build.   Adjust the deployment
> target as needed and for Xcode 3 I'd recommend using CC=gcc-4.2.
>
>    ./configure CFLAGS="-arch i386" LDFLAGS="-arch i386" \
>         CC=clang MACOSX_DEPLOYMENT_TARGET=10.8
>
>> (I'll want to build a dmg installer too, but cross that bridge when I
>> come to it...)
>
> Look at the readme for the installer build script (again, this is the
> more recent 3.3+ version):
>
> http://hg.python.org/cpython/file/default/Mac/BuildScript/README.txt
>
>> NOTE: I'm running 10.7, and would like to use the latest XCode (4.2?),
>> and am OK with the result only working on 10.7+ systems, though 10.6
>> and above would be nice.
>
> Set the deployment target env variable to 10.6 or whatever version you
> need.  By the way, at the moment, the latest version of Xcode for 10.7
> and 10.8 is Xcode 4.5.1 available for free through App Store.app.
>
> There are some gotchas with the most recent versions of Xcode 4.  Among
> them are the elimination of the use of the /Developer directory; now
> things like SDKs are contained within Xcode.app itself.  You can find
> them using xcodebuild:
>
>     xcodebuild -version -sdk macosx10.7 Path
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve
> loper/SDKs/MacOSX10.7.sdk
>
> And, after installing/updating Xcode.app, you also need to install the
> "Command Line Tools" component of Xcode from Xcode -> Preferences.  That
> installs things like clang, make, ld, and system include files into
> their conventional places within /usr.
>
> Good luck!
>
> --
>  Ned Deily,
>  nad at acm.org
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



-- 

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 epperly2 at llnl.gov  Thu Oct 25 16:50:59 2012
From: epperly2 at llnl.gov (Tom Epperly)
Date: Thu, 25 Oct 2012 07:50:59 -0700
Subject: [Pythonmac-SIG] Embedded Python seems broken on Mac OS X Mountain
	LIon
Message-ID: <508951D3.7080805@llnl.gov>

I am trying to work with Apple Mountain Lion's install of Python 2.7. I
have a language interoperability tool, Babel
http://www.llnl.gov/CASC/components/, that used embedded Python when
other languages are calling Python (c.g., C++ calling Python). My
fundamental problem is that sys.path is not being initialized the same
when I dlopen(libpython2.7.dylib) and initialize Python compared with
how the sys.path is set when the Python executable is called directly.
This causes Python to fail to load the numpy module used by Babel.

bash-3.2$ /usr/bin/python2.7 -c "import sys; print sys.path; import
numpy">  /tmp/out1
bash-3.2$ /usr/bin/python -c "import sys; print sys.path; import numpy"
>  /tmp/out2
bash-3.2$ cat /tmp/out1
['',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
'/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC',
'/Library/Python/2.7/site-packages']
bash-3.2$ diff /tmp/out1 /tmp/out2
bash-3.2$ ls -al /usr/bin/python2.7
lrwxr-xr-x  1 root  wheel  75 Aug 23 11:10 /usr/bin/python2.7 ->
../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7

Presumably, this C program that uses dlopen(), Py_Initialize, and
Py_SimpleString should have exactly the same output.

/** foo.c */
#include<dlfcn.h>
#include<stdio.h>

int
main(int argc, char **argv)
{
   // void *lptr =
dlopen("/System/Library/Frameworks/Python.framework/Python", RTLD_NOW |
RTLD_GLOBAL);
   void *lptr =
dlopen("/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib",
RTLD_NOW | RTLD_GLOBAL);
   if (lptr) {
     void (*pyinit)(void) = dlsym(lptr, "Py_Initialize");
     if (pyinit) {
       int (*runSimple)(const char *);
       (*pyinit)();              /* initialize Python */
       runSimple = dlsym(lptr, "PyRun_SimpleString");
       if (runSimple) {
         (*runSimple)("import sys ; print sys.path; import numpy");
       }
     }
     else {
       fprintf(stderr, "Unable to locate Py_Initialize: %s\n", dlerror());
     }
   }
   else {
     fprintf(stderr, "Error loading Python shared library: %s\n",
dlerror());
   }
}

bash-3.2$ gcc foo.c ; ./a.out
['/usr/lib/python27.zip', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-darwin', '/usr/lib/python2.7/plat-mac',
'/usr/lib/python2.7/plat-mac/lib-scriptpackages',
'/usr/Extras/lib/python', '/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload']
Traceback (most recent call last):
   File "<string>", line 1, in<module>
ImportError: No module named numpy

However as you see, it has a completely different sys.path. I can't seem
to find a way to get it to initialize Python with the same sys.path. It
seems like the libpython2.7.dylib is broken. I am at a loss on how to
fix this or even who to ask for help.

Regards,

Tom Epperly


From ronaldoussoren at mac.com  Fri Oct 26 11:12:35 2012
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 26 Oct 2012 11:12:35 +0200
Subject: [Pythonmac-SIG] Embedded Python seems broken on Mac OS X
	Mountain	LIon
In-Reply-To: <508951D3.7080805@llnl.gov>
References: <508951D3.7080805@llnl.gov>
Message-ID: <B5A50AE4-30C0-4515-9645-72E619222B78@mac.com>


On 25 Oct, 2012, at 16:50, Tom Epperly <epperly2 at llnl.gov> wrote:

> I am trying to work with Apple Mountain Lion's install of Python 2.7. I
> have a language interoperability tool, Babel
> http://www.llnl.gov/CASC/components/, that used embedded Python when
> other languages are calling Python (c.g., C++ calling Python). My
> fundamental problem is that sys.path is not being initialized the same
> when I dlopen(libpython2.7.dylib) and initialize Python compared with
> how the sys.path is set when the Python executable is called directly.
> This causes Python to fail to load the numpy module used by Babel.
> 
> bash-3.2$ /usr/bin/python2.7 -c "import sys; print sys.path; import
> numpy">  /tmp/out1
> bash-3.2$ /usr/bin/python -c "import sys; print sys.path; import numpy"
>> /tmp/out2
> bash-3.2$ cat /tmp/out1
> ['',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload',
> '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC',
> '/Library/Python/2.7/site-packages']
> bash-3.2$ diff /tmp/out1 /tmp/out2
> bash-3.2$ ls -al /usr/bin/python2.7
> lrwxr-xr-x  1 root  wheel  75 Aug 23 11:10 /usr/bin/python2.7 ->
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
> 
> Presumably, this C program that uses dlopen(), Py_Initialize, and
> Py_SimpleString should have exactly the same output.
> 
> /** foo.c */
> #include<dlfcn.h>
> #include<stdio.h>
> 
> int
> main(int argc, char **argv)
> {
>  // void *lptr =
> dlopen("/System/Library/Frameworks/Python.framework/Python", RTLD_NOW |
> RTLD_GLOBAL);
>  void *lptr =
> dlopen("/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib",
> RTLD_NOW | RTLD_GLOBAL);
>  if (lptr) {
>    void (*pyinit)(void) = dlsym(lptr, "Py_Initialize");
>    if (pyinit) {
>      int (*runSimple)(const char *);
>      (*pyinit)();              /* initialize Python */
>      runSimple = dlsym(lptr, "PyRun_SimpleString");
>      if (runSimple) {
>        (*runSimple)("import sys ; print sys.path; import numpy");
>      }
>    }
>    else {
>      fprintf(stderr, "Unable to locate Py_Initialize: %s\n", dlerror());
>    }
>  }
>  else {
>    fprintf(stderr, "Error loading Python shared library: %s\n",
> dlerror());
>  }
> }
> 
> bash-3.2$ gcc foo.c ; ./a.out
> ['/usr/lib/python27.zip', '/usr/lib/python2.7',
> '/usr/lib/python2.7/plat-darwin', '/usr/lib/python2.7/plat-mac',
> '/usr/lib/python2.7/plat-mac/lib-scriptpackages',
> '/usr/Extras/lib/python', '/usr/lib/python2.7/lib-tk',
> '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload']
> Traceback (most recent call last):
>  File "<string>", line 1, in<module>
> ImportError: No module named numpy
> 
> However as you see, it has a completely different sys.path. I can't seem
> to find a way to get it to initialize Python with the same sys.path. It
> seems like the libpython2.7.dylib is broken. I am at a loss on how to
> fix this or even who to ask for help.

Not sure why this doesn't work, py2app uses simular code and that works fine.

What's really odd: when I run this on my machine and print sys.prefix it shows that sys.prefix is /Library/Frameworks/Python.framework instead of /System/.... as I'd expect. When I move the Python framework in /Library/Frameworks aside the program gives the same output as your program, with sys.prefix set to '/usr'.

Apple publishes the source code for the python version they ship, and when I look at <http://www.opensource.apple.com/source/python/python-60.3/2.7/fix/getpath.c.ed> I get the impression that they changed the way sys.prefix is located.   Stock CPython uses a deprecated API and they appear to have switch that to using dlopen API. 

Ronald



> 
> Regards,
> 
> Tom Epperly
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


From michael.mccracken at gmail.com  Fri Oct 26 21:09:03 2012
From: michael.mccracken at gmail.com (Michael McCracken)
Date: Fri, 26 Oct 2012 12:09:03 -0700
Subject: [Pythonmac-SIG] PyObjC NSViewController subclass'
 initWithNibName_bundle_ never returns nil?
Message-ID: <CAG-gt+ybJH3xVOXqdON+-DpG4DS_0bNMFHip99h7yOYvD9n87A@mail.gmail.com>

Hi, I ran into this while writing tests for an NSViewController
subclass, and I was wondering if anyone could help me understand this
behavior:

I wanted to mock out the initWithNibName_bundle_ method, so I could
test the class without a bundle to actually load the nib from.

Mocking objc selectors directly gives errors, but using a trivial
wrapper is an OK workaround.
Here's roughly what I ended up with:

class MyViewController(NSViewController):

    def init_wrapper(self, nibname):
        return super(MyViewController,
self).initWithNibName_bundle_(nibname, None)

    def initWithName_(self, name):
        self = self.init_wrapper("TheNibName")
        if not self:
            return self
        # set up self
        return self

Then I proceeded to patch init_wrapper in my tests so it just returns
self and doesn't call super. This way I avoid getting nil from
initWithNibName_bundle_ because there's no main bundle, and no nib
name?

However, I had a bug in my patch, and noticed that it worked anyway -
eventually I find that super(blah).initWithNibName_bundle_ will always
return self, even when there is no such bundle - even when you pass
None as the nib name. Here's a simple example:

from Cocoa import NSViewController

class Bleh(NSViewController):
    def initWithName_(self, name):
        self = super(Bleh, self).initWithNibName_bundle_(None,
None)#'blargl', None)
        print 'in init, self is', self
        self.name = name
        return self

    def do(self):
        print self.name, "is doing", self

b = Bleh.alloc().initWithName_('basdf')
b.do()

I expected b to be None, and thus to get an error, because the docs
for initWithNibName_bundle_ say it'll return nil.

This is actually convenient for my tests, but I'm wondering if it's a
bug or just something I don't understand about how pyobjc works.

Thanks,
-mike

From wrw at mac.com  Wed Oct 31 22:48:53 2012
From: wrw at mac.com (wrw at mac.com)
Date: Wed, 31 Oct 2012 17:48:53 -0400
Subject: [Pythonmac-SIG] Getting control over the Apple menu
Message-ID: <9A15D3B0-BD98-40BF-9EB2-E58ECE673518@mac.com>

I'm slowly (VERY slowly) getting my arms wrapped around Tkinter and ttk (the themed widgets), but I'm up against a brick wall with menus.

The problem is my "Application" menu (what I believe Tkinter still calls the "Apple" menu, that being an OS9 hold-over according to Google).  I've been all over Google, but can't seem to find the answer - probably because I'm not quite asking the right question.

My problem is that I can't get control over my application/apple menu.  When I'm running in the python interpreter, that menu says Python.  The code below generates an application menu, but puts it to the right of where I want it to be, which would be either incorporated in the Python menu or replacing it.

If I convert the script to a stand-alone application using py2app, I get two menus with the application name, mine is still one to the right of where I want it; the system defaults still appear, but now they appear under my application name.

I've extracted the minimal code to demonstrate my problem below (bits of what would otherwise be the main application are still ghosts).
I'd sure appreciate it if someone could point out what I'm missing.

System details:  OS-X 10.8.2, Python 2.7 from python.org, not Apple's python.

Thanks in advance,
Bill

-----------
#!/usr/bin/env python

from Tkinter import *
import ttk

root = Tk()
root.title("CM GUI test 2")

Main_frame = ttk.Frame(root, width=200, height=100, padding=(3,3,12,12))

def Nada():
    filewin = (Main_frame)
    nada = ttk.Button(filewin, text="Do Nada")
    nada.grid(column=0, row= 0, columnspan=3)

menubar = Menu(root)

applemenu = Menu(menubar, tearoff = FALSE)
applemenu.add_command(label = "About CM_GUI_2", command = Nada)
applemenu.add_command(label = "Check for updates...", command = Nada)
menubar.add_cascade(label = "CM_GUI_2", menu=applemenu)

filemenu = Menu(menubar, tearoff=FALSE)
filemenu.add_command(label='New', command = Nada)
filemenu.add_command(label='Open', command = Nada)
filemenu.add_command(label='Save', command = Nada)
filemenu.add_command(label='Save As...', command = Nada)
filemenu.add_separator()
filemenu.add_command(label="Quit", command=root.quit)
menubar.add_cascade(label="File", menu=filemenu)

Main_frame.grid(column=0, row=0, columnspan=3, rowspan=2, sticky=(N, S, E, W))
root.config(menu = menubar)
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)
Main_frame.columnconfigure(0, weight=1)

root.mainloop()