From rowen at uw.edu  Mon Apr  4 21:04:13 2011
From: rowen at uw.edu (Russell E. Owen)
Date: Mon, 04 Apr 2011 12:04:13 -0700
Subject: [Pythonmac-SIG] Problem with py2app 0.6
References: <rowen-7D0977.13024729032011@news.gmane.org>
	<4A82F88F-1527-40F7-8FC2-293065A66A84@mac.com>
	<C3B25D01-D9ED-494E-96B6-316136F48616@uw.edu>
Message-ID: <rowen-A5324E.12041304042011@news.gmane.org>

In article <C3B25D01-D9ED-494E-96B6-316136F48616 at uw.edu>,
 Russell Owen <rowen at uw.edu> wrote:

> > On 29 Mar, 2011, at 22:02, Russell E. Owen wrote:
> > 
> >> I used easy_install to install py2app 0.6 and tried it out on one of 
> >> several applications I distribute. Unfortunately the build failed with;
> > 
> > The testsuite is obviously not good enough yet to catch all errors.  I've 
> > done some changes in how py2app deals with source files to clean up the 
> > code that deals with zipped egg files, and that obviously introduced a 
> > problem.

Ronald Oussoren fixed the problem in the current py2app "trunk", which 
is a prerelease of 0.6.2.

Thank you very much for the quick fix (which happened last week, but I 
only today had a chance to test it).

-- Russell


From ronaldoussoren at mac.com  Tue Apr  5 11:23:07 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 05 Apr 2011 11:23:07 +0200
Subject: [Pythonmac-SIG] Problem with py2app 0.6
In-Reply-To: <rowen-A5324E.12041304042011@news.gmane.org>
References: <rowen-7D0977.13024729032011@news.gmane.org>
	<4A82F88F-1527-40F7-8FC2-293065A66A84@mac.com>
	<C3B25D01-D9ED-494E-96B6-316136F48616@uw.edu>
	<rowen-A5324E.12041304042011@news.gmane.org>
Message-ID: <43F85B99-BE6E-4407-B27F-C2DE02E2019C@mac.com>


On 4 Apr, 2011, at 21:04, Russell E. Owen wrote:

> In article <C3B25D01-D9ED-494E-96B6-316136F48616 at uw.edu>,
> Russell Owen <rowen at uw.edu> wrote:
> 
>>> On 29 Mar, 2011, at 22:02, Russell E. Owen wrote:
>>> 
>>>> I used easy_install to install py2app 0.6 and tried it out on one of 
>>>> several applications I distribute. Unfortunately the build failed with;
>>> 
>>> The testsuite is obviously not good enough yet to catch all errors.  I've 
>>> done some changes in how py2app deals with source files to clean up the 
>>> code that deals with zipped egg files, and that obviously introduced a 
>>> problem.
> 
> Ronald Oussoren fixed the problem in the current py2app "trunk", which 
> is a prerelease of 0.6.2.

I forgot to report that the fix is already in release 0.6.1.

Ronald

From nathaniel.echols at gmail.com  Wed Apr  6 01:48:19 2011
From: nathaniel.echols at gmail.com (Nat Echols)
Date: Tue, 5 Apr 2011 16:48:19 -0700
Subject: [Pythonmac-SIG] py2app improperly using system framework
Message-ID: <BANLkTinxruUoz6dzYjXTLzSpJ_Hc=TUMCw@mail.gmail.com>

I'm using py2app from the latest SVN, along with an installation of Python
2.7 in a non-standard location.  I don't get any error messages during
running either py2applet or 'setup.py py2app', but at some point during app
building, it starts copying over parts of the system's Python (2.6!)
installation.  Here is where it starts to fall apart:

copying /net/clover/scratch1/python/bin/python ->
/private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/MacOS
linking
/private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Python
-> Versions/Current/Python
linking
/private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Resources
-> Versions/Current/Resources
copying /Library/Frameworks/python.framework/Versions/2.6/bin/2to3 ->
/private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Versions/2.6/bin

and then it proceeds to copy over most of the modules from 2.6.  The
resulting app is unusable, because it has the Python 2.7 binary which
expects the modules in a 'python2.7' folder, but it's actually 'python2.6'.
 I've tried reinstalling everything multiple times and nothing I have tried
works.  This was working fine on 10.4 with py2app 0.5.2, but I had to
upgrade py2app for it to even run on Snow Leopard.  What am I missing here?

thanks,
Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110405/08e54f24/attachment.html>

From phammer at cardious.com  Mon Apr  4 07:24:31 2011
From: phammer at cardious.com (Temescal)
Date: Sun, 3 Apr 2011 22:24:31 -0700 (PDT)
Subject: [Pythonmac-SIG]  Simple PyObjC question: real or vapor?
Message-ID: <31311493.post@talk.nabble.com>


3 April 2011

My goal:

Using my MacBook (intel 64 bit dual core), OSX 10.6.7, standard System
python frameworks
(2.6,2.5,2.3), a standard python install of 2.7 (32 bit) in a Library
framework, Xcode 3.2.5, I would
like to write some GUI based python programs for the Mac.

My problem: 

1) The Apple developer article "Using PyObjC for Developing Cocoa
Applications with Python" is
hopelessly outdated.  PyObjC and py2app are not under the Developer folder
but are under the
System/Library/Frameworks/.../Extras/lib/python folder.  Xcode new project
has no option for selecting
a PyObjC application, etc.

2) The PyObjC website ambiguously states
"The stable release front is rather hazy at the moment, I'm sorry for that
and intend to fix that in
the near feature."  The indications are, this was composed some time ago, as
2.3 appears to be the
current package.  The web site advises using easy_install, but the web has
widely conflicting opinions
on easy_install's value, and moreover the recommended command "$
easy_install pyobjc=2.2b1" fails.

3) I've used easy_install successfully exactly once to install lxml.  I've
shunned MacPorts and Fink
because of the various web reports about their frailty, and also because
using them seems to be
incomprehensibly complex.  I tried a variation on the PyObjC command:
"$easy_install pyobjc"
which runs, giving a plethora of errors, and installs various eggs in
/Library/Python/2.6/site-packages,
this despite "$which python" offers up python 2.7 as the default python. 
Moreover, as reported in
another thread, _ScreenSaver fails to install.  _2to3 is not recognized as a
distribution option, suggesting
that perhaps python 3 needs to be installed, but logically, if that were the
case, it should be so
reported by easy_install.  Or, perhaps it can't find 2to3 which is in the
standard Mac python distribution.

Using "$easy_install py2app" works except for failing to install macholib,
which is apparently crucial to
running /usr/local/bin/py2applet, which it also installs.

4) Xcode 4, which I just learned about, seems to not support python at all,
according to threads here.

5) Contributions to the various threads in this forum seem to be divided
among those who, like me,
are completely confused and frustrated, and those who seem to have working
useful systems up and
running and don't see any issues at all.

My request:

So in summary, in very simple terms, can anyone tell me how to accomplish my
goal or tell me why
my goal is unachievable with my existing tools, and what if anything can be
done to correct the
situation?  I've probably put 40 hours of time into web searches and trying
various things.  It can't
be this hard, and if it really is this hard, I just won't be writing GUI
apps for the Mac, because
I really like python, more than any other language I've used.  I like python
because it is clear, it
works, it is well documented, and it is complete.  Thus far, PyObjC is none
of these.

-- 
View this message in context: http://old.nabble.com/Simple-PyObjC-question%3A-real-or-vapor--tp31311493p31311493.html
Sent from the Python - pythonmac-sig mailing list archive at Nabble.com.


From hraban at fiee.net  Wed Apr  6 13:39:26 2011
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Wed, 6 Apr 2011 13:39:26 +0200
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <31311493.post@talk.nabble.com>
References: <31311493.post@talk.nabble.com>
Message-ID: <12967520-41B1-4353-A255-F3EFA8E151F9@fiee.net>

Disclaimer: I know nothing about PyObjC.

Am 2011-04-04 um 07:24 schrieb Temescal:

> 3) I've used easy_install successfully exactly once to install  
> lxml.  I've
> shunned MacPorts and Fink
> because of the various web reports about their frailty, and also  
> because
> using them seems to be
> incomprehensibly complex.

I use MacPorts all the time and used Fink on earlier systems. (And I  
guess Homebrew is similar.)
I don?t know what you would call "incomprehensibly complex" about any  
of them.

It?s normally not advised to use Port?s or Fink?s python, esp. to do  
any Mac-specific stuff, because they follow a "general UNIX/Linux"  
approach, i.e. use X11. If you don?t need any other "ported" stuff,  
you might be annoyed that they pull in "a complete Linux system".

Normally the best advice is to use python.org?s distribution.  
Sometimes ActiveState?s may be better.

> 4) Xcode 4, which I just learned about, seems to not support python  
> at all,
> according to threads here.

Probably not true - python support in XCode 4 seems different than in  
previous versions, but it?s there.
(As far as I read the latest thread on that subject - never tried  
python with any XCode myself.)

> be this hard, and if it really is this hard, I just won't be writing  
> GUI
> apps for the Mac, because
> I really like python, more than any other language I've used.  I  
> like python
> because it is clear, it
> works, it is well documented, and it is complete.  Thus far, PyObjC  
> is none
> of these.

Why don?t you use wxPython? (I suggest to use it via the "dabo"  
wrapper, esp. for data-centric applications; see http://dabodev.com)
There *are* reasons against wx, but perhaps none of them is yours.


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





From ronaldoussoren at mac.com  Wed Apr  6 15:27:45 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 06 Apr 2011 13:27:45 +0000 (GMT)
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <31311493.post@talk.nabble.com>
Message-ID: <1aa4eb0a-0fca-6b52-a544-eb12ac710a15@me.com>

(Sorry about the formatting of the e-mail, MobileMe's webmail and mailinglists don't like each other)

On 06 Apr, 2011,at 01:10 PM, Temescal <phammer at cardious.com> wrote:


3 April 2011

My goal:

Using my MacBook (intel 64 bit dual core), OSX 10.6.7, standard System
python frameworks
(2.6,2.5,2.3), a standard python install of 2.7 (32 bit) in a Library
framework, Xcode 3.2.5, I would
like to write some GUI based python programs for the Mac.

My problem: 

1) The Apple developer article "Using PyObjC for Developing Cocoa
Applications with Python" is
hopelessly outdated. PyObjC and py2app are not under the Developer folder
but are under the
System/Library/Frameworks/.../Extras/lib/python folder Xcode new project
has no option for selecting
a PyObjC application, etc.
?

Xcode no longer includes the PyObjC templates and I haven't packaged them yet (mostly because they IMO need changes and I haven't had time to dig into that yet, and changing templates requires a lot of time because there are no useful tools that make it easier to work with templates).



2) The PyObjC website ambiguously states
"The stable release front is rather hazy at the moment, I'm sorry for that
and intend to fix that in
the near feature." The indications are, this was composed some time ago, as
2.3 appears to be the
current package. The web site advises using easy_install, but the web has
widely conflicting opinions
on easy_install's value, and moreover the recommended command "$
easy_install pyobjc=2.2b1" fails.
?

Easy_install for version 2.3 should work. I finally have a working test setup again and hope to start working on pyobjc 2.4 again.


3) I've used easy_install successfully exactly once to install lxml. I've
shunned MacPorts and Fink
because of the various web reports about their frailty, and also because
using them seems to be
incomprehensibly complex. I tried a variation on the PyObjC command:
"$easy_install pyobjc"
which runs, giving a plethora of errors, and installs various eggs in
/Library/Python/2.6/site-packages,
this despite "$which python" offers up python 2.7 as the default python. 
Moreover, as reported in
another thread, _ScreenSaver fails to install. _2to3 is not recognized as a
distribution option, suggesting
that perhaps python 3 needs to be installed, but logically, if that were the
case, it should be so
reported by easy_install. Or, perhaps it can't find 2to3 which is in the
standard Mac python distribution.

I don't use fink or macports myself, but appearently these work just fine if you don't care about having a separate unix install in their package tree.

Using "$easy_install py2app" works except for failing to install macholib,
which is apparently crucial to
running /usr/local/bin/py2applet, which it also installs.
?
Easy_install py2app should work, please send my the output of the failing easy_install.



4) Xcode 4, which I just learned about, seems to not support python at all,
according to threads here.
?

The last preview I checked didn't support Python, but recently someone mentioned that the final release does support Python.



5) Contributions to the various threads in this forum seem to be divided
among those who, like me,
are completely confused and frustrated, and those who seem to have working
useful systems up and
running and don't see any issues at all.

My request:

So in summary, in very simple terms, can anyone tell me how to accomplish my
goal or tell me why
my goal is unachievable with my existing tools, and what if anything can be
done to correct the
situation? I've probably put 40 hours of time into web searches and trying
various things. It can't
be this hard, and if it really is this hard, I just won't be writing GUI
apps for the Mac, because
I really like python, more than any other language I've used. I like python
because it is clear, it
works, it is well documented, and it is complete. Thus far, PyObjC is none
of these.
?
The installation of PyObjC should, and shall, be improved but there is documentation. The most important documentation page is <http://pyobjc.sourceforge.net/documentation/pyobjc-core/intro.html>, which explains how PyObjC works. ?There is no documentation on Apple's frameworks beyond listing unsupported features, and that's by design: the existing ObjC documentation is easy to read and it should be easy enough to mentally translate the ObjC idioms in Apple's documentation to Python.

A big issue w.r.t. PyObjC and py2app is that this is a pretty large project with a single maintainer. What doesn't help is that I barely have time to work PyObjC, which is why development is going slowly and the website hasn't been updated in ages. ?Development speed is unlikely to change in the forseeable future.

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110406/92336c48/attachment-0001.html>

From Chris.Barker at noaa.gov  Wed Apr  6 18:15:20 2011
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 06 Apr 2011 09:15:20 -0700
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <31311493.post@talk.nabble.com>
References: <31311493.post@talk.nabble.com>
Message-ID: <4D9C9198.9040800@noaa.gov>

just one more note:

On 4/3/11 10:24 PM, Temescal wrote:
>   I tried a variation on the PyObjC command:
> "$easy_install pyobjc"
> which runs, giving a plethora of errors, and installs various eggs in
> /Library/Python/2.6/site-packages,
> this despite "$which python" offers up python 2.7 as the default python.

you need "$which easy_install" to make sure you are running the right 
easy-install.

It's possible you have not installed setuptools properly (or at all) in 
your python2.7


Don't know anythign about pyObjC, sorry.

wxPython is a pretty good option, though. Probably not as good as pyObjC 
for Mac-only stuff, but it's great for multi platform development, and 
does work quite well on OS-X.

-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 nathaniel.echols at gmail.com  Wed Apr  6 23:18:11 2011
From: nathaniel.echols at gmail.com (Nat Echols)
Date: Wed, 6 Apr 2011 14:18:11 -0700
Subject: [Pythonmac-SIG] py2app improperly using system framework
In-Reply-To: <4ADB1073-35FB-4655-8371-D599B2B8DC22@mac.com>
References: <BANLkTinxruUoz6dzYjXTLzSpJ_Hc=TUMCw@mail.gmail.com>
	<4ADB1073-35FB-4655-8371-D599B2B8DC22@mac.com>
Message-ID: <BANLkTi=ygW+xBVeJgU2JeFGKm3+nv7q5rA@mail.gmail.com>

On Wed, Apr 6, 2011 at 1:26 PM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

> Could you try the latest release on PyPI?  This is just to check if that
> version also has the problem you describe, which I haven't seen before even
> though I have a number of versions installed on my machine.
>

Actually, I finally fixed the problem by re-installing everything I needed
from scratch in /usr/local and using that copy, so I guess I must have done
something wrong along the way with my original install.  For the record, the
configure flags for Python were:

./configure --enable-shared --prefix=/usr/local

Is this appropriate, and/or am I missing anything?

thanks,
Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110406/176402d4/attachment.html>

From ronaldoussoren at mac.com  Wed Apr  6 22:26:30 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 06 Apr 2011 22:26:30 +0200
Subject: [Pythonmac-SIG] py2app improperly using system framework
In-Reply-To: <BANLkTinxruUoz6dzYjXTLzSpJ_Hc=TUMCw@mail.gmail.com>
References: <BANLkTinxruUoz6dzYjXTLzSpJ_Hc=TUMCw@mail.gmail.com>
Message-ID: <4ADB1073-35FB-4655-8371-D599B2B8DC22@mac.com>


On 6 Apr, 2011, at 1:48, Nat Echols wrote:

> I'm using py2app from the latest SVN, along with an installation of Python 2.7 in a non-standard location.  I don't get any error messages during running either py2applet or 'setup.py py2app', but at some point during app building, it starts copying over parts of the system's Python (2.6!) installation.  Here is where it starts to fall apart:
> 
> copying /net/clover/scratch1/python/bin/python -> /private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/MacOS
> linking /private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Python -> Versions/Current/Python
> linking /private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Resources -> Versions/Current/Resources
> copying /Library/Frameworks/python.framework/Versions/2.6/bin/2to3 -> /private/var/tmp/mac_app-dev-720/dist/PHENIX-dev-720.app/Contents/Frameworks/python.framework/Versions/2.6/bin
> 
> and then it proceeds to copy over most of the modules from 2.6.  The resulting app is unusable, because it has the Python 2.7 binary which expects the modules in a 'python2.7' folder, but it's actually 'python2.6'.  I've tried reinstalling everything multiple times and nothing I have tried works.  This was working fine on 10.4 with py2app 0.5.2, but I had to upgrade py2app for it to even run on Snow Leopard.  What am I missing here?
> 
Could you try the latest release on PyPI?  This is just to check if that version also has the problem you describe, which I haven't seen before even though I have a number of versions installed on my machine.

Ronald

> thanks,
> Nat
> _______________________________________________
> 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 ronaldoussoren at mac.com  Wed Apr  6 22:33:36 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 06 Apr 2011 22:33:36 +0200
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <4D9C9198.9040800@noaa.gov>
References: <31311493.post@talk.nabble.com> <4D9C9198.9040800@noaa.gov>
Message-ID: <C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>


On 6 Apr, 2011, at 18:15, Christopher Barker wrote:
> 
> 
> wxPython is a pretty good option, though. Probably not as good as pyObjC for Mac-only stuff, but it's great for multi platform development, and does work quite well on OS-X.

I don't agree with your opionion on wxPython, last time I checked it sucked for cross platform development because code doesn't always work the same way on different platforms (one example I remember from the last time I fought with wxWidgets is the background color of text entry fields, changing that on Windows is easy enough but the same code doesn't work on OSX).

I must admit that I haven't worked with the OSX version of wx for a couple of years though, because of x-platform issues I switched to running a Windows VM whenever I need to write GUI code that might need to run on Windows.

But at least wxWidgets isn't Tk, the OSX port of Tk seems to get worse over time :-(. We've moved from IDLE not looking quite right to IDLE just crashing with TkCocoa (for example when using a number of keyboard shortcuts).

Ronald


From kw at codebykevin.com  Thu Apr  7 00:01:09 2011
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 06 Apr 2011 18:01:09 -0400
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>
References: <31311493.post@talk.nabble.com> <4D9C9198.9040800@noaa.gov>
	<C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>
Message-ID: <4D9CE2A5.3090404@codebykevin.com>

On 4/6/11 4:33 PM, Ronald Oussoren wrote:
> But at least wxWidgets isn't Tk, the OSX port of Tk seems to get worse over time:-(. We've moved from IDLE not looking quite right to IDLE just crashing with TkCocoa (for example when using a number of keyboard shortcuts).

I think, to be fair, that it should be pointed out that the version of 
Tk shipping with SL is quite buggy--as is usually the case with Apple, 
they do not update such libraries with OS update. Users report that 
recent versions of ActiveTcl's Cocoa build work quite well with IDLE--a 
lot of bug fixing has gone on with both Tk and Tkinter's integration of 
the Cocoa version of Tk.

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

From Chris.Barker at noaa.gov  Wed Apr  6 23:48:52 2011
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 06 Apr 2011 14:48:52 -0700
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>
References: <31311493.post@talk.nabble.com> <4D9C9198.9040800@noaa.gov>
	<C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>
Message-ID: <4D9CDFC4.8040509@noaa.gov>

On 4/6/11 1:33 PM, Ronald Oussoren wrote:
> I don't agree with your opinion on wxPython, last time I checked it sucked for cross platform development because code doesn't always work the same way on different platforms (one example I remember from the last time I fought with wxWidgets is the background color of text entry fields, changing that on Windows is easy enough but the same code doesn't work on OSX).

Well, all that is true, but what that tells me is that cross-platform 
development sucks. wxWidgets does it pretty well, considering.

You could go with QT, and then things will probably work pretty much the 
same on all platforms, but they won't look or act native (particularly 
on the Mac)

> I must admit that I haven't worked with the OSX version of wx for a couple of years though, because of x-platform issues I switched to running a Windows VM whenever I need to write GUI code that might need to run on Windows.

Well, you certainly want to test early and often on all the platforms 
you want to support. In general, if you do things the recommended way, 
it will work on all platforms, but it is pretty easy to do something in 
a way that only works in one place -- in that case, you want to catch 
those things early by testing early.

That's all a bit of a pain, but a LOT easier than writing 3 GUIs.

If you only want to develop Mac apps, Cocoa (via PyObjC) is the way to go.

> But at least wxWidgets isn't Tk, the OSX port of Tk seems to get worse over time :-(. We've moved from IDLE not looking quite right to IDLE just crashing with TkCocoa (for example when using a number of keyboard shortcuts).

yeach.

In fact, the latest wx uses Cocoa (oit had been Carbon). I haven't used 
it yet, but once the bugs get ironed out, it should take us well into 
the future on the Mac.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Thu Apr  7 10:20:55 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 07 Apr 2011 10:20:55 +0200
Subject: [Pythonmac-SIG] py2app improperly using system framework
In-Reply-To: <BANLkTi=ygW+xBVeJgU2JeFGKm3+nv7q5rA@mail.gmail.com>
References: <BANLkTinxruUoz6dzYjXTLzSpJ_Hc=TUMCw@mail.gmail.com>
	<4ADB1073-35FB-4655-8371-D599B2B8DC22@mac.com>
	<BANLkTi=ygW+xBVeJgU2JeFGKm3+nv7q5rA@mail.gmail.com>
Message-ID: <EE96AC55-4767-42F6-AB24-DF1EA671A7B7@mac.com>


On 6 Apr, 2011, at 23:18, Nat Echols wrote:

> On Wed, Apr 6, 2011 at 1:26 PM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> Could you try the latest release on PyPI?  This is just to check if that version also has the problem you describe, which I haven't seen before even though I have a number of versions installed on my machine.
> 
> Actually, I finally fixed the problem by re-installing everything I needed from scratch in /usr/local and using that copy, so I guess I must have done something wrong along the way with my original install.  For the record, the configure flags for Python were:
> 
> ./configure --enable-shared --prefix=/usr/local
> 
> Is this appropriate, and/or am I missing anything?

That should work just fine. The --prefix is unnecessary here as /usr/local is the default prefix.

One minor nit is that I tend avoid to install anything in /usr/local because /usr/local is on the default search path of the compiler, which means you can accidently pick up other libraries than you expect if you install stuff in /usr/local.

Ronald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110407/eaf243e8/attachment.html>

From ronaldoussoren at mac.com  Thu Apr  7 10:31:15 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 07 Apr 2011 10:31:15 +0200
Subject: [Pythonmac-SIG] Simple PyObjC question: real or vapor?
In-Reply-To: <4D9CE2A5.3090404@codebykevin.com>
References: <31311493.post@talk.nabble.com> <4D9C9198.9040800@noaa.gov>
	<C98E7685-0FDC-4C73-BBD9-DF1D4737F20A@mac.com>
	<4D9CE2A5.3090404@codebykevin.com>
Message-ID: <58C71476-1D94-419E-8C66-9FEFB416869A@mac.com>


On 7 Apr, 2011, at 0:01, Kevin Walzer wrote:

> On 4/6/11 4:33 PM, Ronald Oussoren wrote:
>> But at least wxWidgets isn't Tk, the OSX port of Tk seems to get worse over time:-(. We've moved from IDLE not looking quite right to IDLE just crashing with TkCocoa (for example when using a number of keyboard shortcuts).
> 
> I think, to be fair, that it should be pointed out that the version of Tk shipping with SL is quite buggy--as is usually the case with Apple, they do not update such libraries with OS update. Users report that recent versions of ActiveTcl's Cocoa build work quite well with IDLE--a lot of bug fixing has gone on with both Tk and Tkinter's integration of the Cocoa version of Tk.

The crashes also happen with the latest ActiveState build of TkCocoa.   As an example you could try to run a script using F5.  I have a workaround for that, which I really need to commit soon, but the root cause of the crash is a bug in TkCocoa.

Ronald


From janssen at parc.com  Thu Apr  7 22:48:34 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Apr 2011 13:48:34 PDT
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
Message-ID: <64461.1302209314@parc.com>

I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
I'd try Python 2.7 on it.  Normally, I advise people to never try to
install a different Python on a Mac, as it's too embedded in the OS to
do safely, without a great deal of domain knowledge.  But here, I
figured I could always wipe the disk and start over without too much
loss.

So I ran the installer, and tried a few things, and it didn't solve my
buildbot problems.  So I decided to go back to the original System
python.  But now I find that the installer has put the 2.7 Python on my
PATH?!?  It does this apparently by hacking ~/.bash_profile.  In there,
there's a line saying

  The original version is saved in .bash_profile.pysave

a file which doesn't seem to exist.

So, why didn't I notice myself checking the checkbox to do this in the
first place, and where is my original .bash_profile file?

Bill

From nad at acm.org  Fri Apr  8 00:37:26 2011
From: nad at acm.org (Ned Deily)
Date: Thu, 07 Apr 2011 15:37:26 -0700
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
References: <64461.1302209314@parc.com>
Message-ID: <nad-11CAEA.15372607042011@news.gmane.org>

In article <64461.1302209314 at parc.com>, Bill Janssen <janssen at parc.com> 
wrote:
> I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
> I'd try Python 2.7 on it.  Normally, I advise people to never try to
> install a different Python on a Mac, as it's too embedded in the OS to
> do safely, without a great deal of domain knowledge.  But here, I
> figured I could always wipe the disk and start over without too much
> loss.

I don't understand why you would say that.  The huge advantage of the 
Python framework installation layout on OS X is precisely that it 
*doesn't* get embedded into the OS and *does* allow multiple versions of 
Python to co-exist on a system far more easily and safely than with the 
traditional Python Unix layout.  With a very few exceptions, all of the 
files installed are under one root 
(Library/Frameworks/Python.framework/Versions/m.n/) with some auxiliary 
files under another (/Applications/Python m.n) and optionally some 
symlinks in /usr/local/bin, with *zero* overlap with any Apple-supplied 
files in OS X including the Apple-supplies Pythons.  If for some reason 
you do want to uninstall a framework build, it's a matter of two 'rm' 
commands and optionally removing some obvious symlinks in /usr/local/bin 
(which are not needed in the first place).  An official uninstall 
command would be nice to have and has been requested in the past (see 
http://bugs.python.org/issue7107).

If you are aware of problems where multiple framework installs cannot be 
installed safely, please open issues for them.
 
> So I ran the installer, and tried a few things, and it didn't solve my
> buildbot problems.  So I decided to go back to the original System
> python.  But now I find that the installer has put the 2.7 Python on my
> PATH?!?  It does this apparently by hacking ~/.bash_profile.  In there,
> there's a line saying
> 
>   The original version is saved in .bash_profile.pysave
> 
> a file which doesn't seem to exist.
> 
> So, why didn't I notice myself checking the checkbox to do this in the
> first place, and where is my original .bash_profile file?

The Python 2.7.1 installer welcome file, the text that is shown in the 
first installer screen, says this:

"This package will by default update your shell profile to ensure that 
this version of Python is on the search path of your shell. Please 
deselect the "Shell profile updater" package on the package 
customization screen if you want to avoid this modification.  
Double-click Update Shell Profile at any time to make 2.7.1 the default 
Python."

(Earlier installers had slightly different wordings.)

The command that does this is in /Applications/Python m.n/Update Shell 
Profile.command.  Normally, it should have saved your .bash_profile as 
~/.bash_profile.pysave, but, even if it didn't, the only modification it 
makes to your original .bash_profile is to append these (or similar) 
lines to the end of the file:

# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH

Hope that helps!

-- 
 Ned Deily,
 nad at acm.org


From rowen at uw.edu  Fri Apr  8 00:56:56 2011
From: rowen at uw.edu (Russell E. Owen)
Date: Thu, 07 Apr 2011 15:56:56 -0700
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
References: <64461.1302209314@parc.com>
Message-ID: <rowen-81D53B.15565607042011@news.gmane.org>

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

> I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
> I'd try Python 2.7 on it.  Normally, I advise people to never try to
> install a different Python on a Mac, as it's too embedded in the OS to
> do safely, without a great deal of domain knowledge.  But here, I
> figured I could always wipe the disk and start over without too much
> loss.
> 
> So I ran the installer, and tried a few things, and it didn't solve my
> buildbot problems.  So I decided to go back to the original System
> python.  But now I find that the installer has put the 2.7 Python on my
> PATH?!?  It does this apparently by hacking ~/.bash_profile.  In there,
> there's a line saying
> 
>   The original version is saved in .bash_profile.pysave
> 
> a file which doesn't seem to exist.
> 
> So, why didn't I notice myself checking the checkbox to do this in the
> first place, and where is my original .bash_profile file?

I'm surprised you can't find it. I've always had it saved on some 
obvious place. But I agree that hacking the file is ugly -- it least it 
could ask.

In any case you can revert by just deleting the extra lines.

Other gripes about the installer:
- It names the version explicitly instead of using the Current symlink 
(/Libraries/Packages/Python.Package/Versions/Current).
- It hacks the file even if doesn't need to (e.g. if Current is already 
on the $PATH then the new python will be found; I think that would be 
easy to check).
- It adds a bunch of links to /usr/local/bin even though that is 
redundant with putting Python's bin directory on the $PATH. This makes 
it a headache to switch Python versions -- something developers often 
need to do when testing compatibility.

That said, they're minor annoyances and I've not come forward to fix any 
of them. And the resulting python works nicely.

-- Russell


From nad at acm.org  Fri Apr  8 01:23:29 2011
From: nad at acm.org (Ned Deily)
Date: Thu, 07 Apr 2011 16:23:29 -0700
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
References: <64461.1302209314@parc.com>
	<rowen-81D53B.15565607042011@news.gmane.org>
Message-ID: <nad-C631DE.16232907042011@news.gmane.org>

In article <rowen-81D53B.15565607042011 at news.gmane.org>,
 "Russell E. Owen" <rowen at uw.edu> wrote:
> I'm surprised you can't find it. I've always had it saved on some 
> obvious place. But I agree that hacking the file is ugly -- it least it 
> could ask.

Well, as I noted, the installer actually does warn you and give you the 
option to not hack it, if you follow through and click on the Customize 
button.  Python 3 installers come with that option deselected by 
default, by the way, and, yes, the hack is ugly.  I hope we can 
something a bit more elegant by the time 3.3 releases.

> Other gripes about the installer:
> - It names the version explicitly instead of using the Current symlink 
> (/Libraries/Packages/Python.Package/Versions/Current).

Sorry, I don't understand that.

> - It hacks the file even if doesn't need to (e.g. if Current is already 
> on the $PATH then the new python will be found; I think that would be 
> easy to check).

Oh, I see.  You meant with regards to how $PATH is set up.  One problem 
with that now is that it is quite reasonable to have both a Python 2 and 
a Python 3 version "active" at the same time so the "Current" symlink is 
of less value than it once was.  In fact, the Python 3 installers 
deliberately do not alter "Current".  AFAIK, there is no other problem 
with having both a Python 2 bin and Python 3 bin directory on $PATH 
simultaneously as there is no overlap between the standard file names: 
all of the Python 3 bin files have a "3" included in them.  (The one 
exception to that at the moment is "2to3" which is a bit of a special 
case but there are versioned names, 2to3-3.2 and 2to3-2.7, if it is 
necessary to distinguish them.)

A case could be made I guess for using a different framework name, say 
Python3, so that there could be separate Current values for 2 and 3.  
But, I think there are bigger opportunities to rethink the installation 
process and layouts for Python 3.3.

> - It adds a bunch of links to /usr/local/bin even though that is 
> redundant with putting Python's bin directory on the $PATH. This makes 
> it a headache to switch Python versions -- something developers often 
> need to do when testing compatibility.

The installation of those links can also be disabled in the installer's 
Customize panel.  But, yes, I've come around to the thinking that those 
links cause more trouble that they are worth, especially since the 
framework bin directory is where Distutils-installed script files get 
installed.  Another potential change for 3.3.

> That said, they're minor annoyances and I've not come forward to fix any 
> of them. And the resulting python works nicely.

I guess that's the most important part :)

-- 
 Ned Deily,
 nad at acm.org


From janssen at parc.com  Fri Apr  8 02:03:21 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Apr 2011 17:03:21 PDT
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
In-Reply-To: <nad-11CAEA.15372607042011@news.gmane.org>
References: <64461.1302209314@parc.com>
	<nad-11CAEA.15372607042011@news.gmane.org>
Message-ID: <69649.1302221001@parc.com>

Ned Deily <nad at acm.org> wrote:

> In article <64461.1302209314 at parc.com>, Bill Janssen <janssen at parc.com> 
> wrote:
> > I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
> > I'd try Python 2.7 on it.  Normally, I advise people to never try to
> > install a different Python on a Mac, as it's too embedded in the OS to
> > do safely, without a great deal of domain knowledge.  But here, I
> > figured I could always wipe the disk and start over without too much
> > loss.
> 
> I don't understand why you would say that.

I think it's gotten immensely better over the years, thanks to the
efforts of folks like you and Ronald.  But I still think it tends to
have too many side-effects which surprise and confuse people.

> The huge advantage of the 
> Python framework installation layout on OS X is precisely that it 
> *doesn't* get embedded into the OS and *does* allow multiple versions of 
> Python to co-exist on a system far more easily and safely than with the 
> traditional Python Unix layout.  With a very few exceptions, all of the 
> files installed are under one root 
> (Library/Frameworks/Python.framework/Versions/m.n/) with some auxiliary 
> files under another (/Applications/Python m.n) and optionally some 
> symlinks in /usr/local/bin, with *zero* overlap with any Apple-supplied 
> files in OS X including the Apple-supplies Pythons.  If for some reason 
> you do want to uninstall a framework build, it's a matter of two 'rm' 
> commands and optionally removing some obvious symlinks in /usr/local/bin 
> (which are not needed in the first place).  An official uninstall 
> command would be nice to have and has been requested in the past (see 
> http://bugs.python.org/issue7107).

Yes, that would be nice.

> > So, why didn't I notice myself checking the checkbox to do this in the
> > first place, and where is my original .bash_profile file?
> 
> The Python 2.7.1 installer welcome file, the text that is shown in the 
> first installer screen, says this:
> 
> "This package will by default update your shell profile to ensure that 
> this version of Python is on the search path of your shell. Please 
> deselect the "Shell profile updater" package on the package 
> customization screen if you want to avoid this modification.  
> Double-click Update Shell Profile at any time to make 2.7.1 the default 
> Python."

So it's a default operation.

> (Earlier installers had slightly different wordings.)
> 
> The command that does this is in /Applications/Python m.n/Update Shell 
> Profile.command.  Normally, it should have saved your .bash_profile as 
> ~/.bash_profile.pysave, but, even if it didn't, the only modification it 
> makes to your original .bash_profile is to append these (or similar) 
> lines to the end of the file:
> 
> # Setting PATH for Python 2.7
> # The orginal version is saved in .bash_profile.pysave
> PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
> export PATH
> 
> Hope that helps!

Yes, thanks, very complete explanation.  Like I said, I never run this
installer, so lack of familiarity on my part is most of the problem.

Though, I wouldn't have defaulted that path hacking to "On".  But I
understand the problem with the range of user knowledge you guys are
trying to cope with.

Bill

From Chris.Barker at noaa.gov  Fri Apr  8 01:07:19 2011
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 07 Apr 2011 16:07:19 -0700
Subject: [Pythonmac-SIG] why does the Mac installer hack the
	user's	.bash_profile?
In-Reply-To: <nad-11CAEA.15372607042011@news.gmane.org>
References: <64461.1302209314@parc.com>
	<nad-11CAEA.15372607042011@news.gmane.org>
Message-ID: <4D9E43A7.4000901@noaa.gov>

On 4/7/11 3:37 PM, Ned Deily wrote:

> The Python 2.7.1 installer welcome file, the text that is shown in the
> first installer screen, says this:
>
> "This package will by default update your shell profile to ensure that
> this version of Python is on the search path of your shell. Please
> deselect the "Shell profile updater" package on the package
> customization screen if you want to avoid this modification.
> Double-click Update Shell Profile at any time to make 2.7.1 the default
> Python."
>
> (Earlier installers had slightly different wordings.)
>
> The command that does this is in /Applications/Python m.n/Update Shell
> Profile.command.  Normally, it should have saved your .bash_profile as
> ~/.bash_profile.pysave, but, even if it didn't, the only modification it
> makes to your original .bash_profile is to append these (or similar)
> lines to the end of the file:
>
> # Setting PATH for Python 2.7
> # The original version is saved in .bash_profile.pysave
> PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
> export PATH

And a note: before the installer did that, we had a LOT of newbies 
installing python and then having no idea how to get it to run.

I'm a bit confused, Bill. You're just that kind of guy that shouldn't 
have any problem hacking your .bash_profile! i.e. you are not the target 
audience for the installer.

Also: I'm pretty sure it's Apple's fault that a de-installer is not a 
easy and obvious part of a .mpg bundle. I don't think I've ever seen one 
with a uninstaller, as a matter of fact.

-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  Fri Apr  8 07:58:15 2011
From: janssen at parc.com (Bill Janssen)
Date: Thu, 7 Apr 2011 22:58:15 PDT
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
In-Reply-To: <4D9E43A7.4000901@noaa.gov>
References: <64461.1302209314@parc.com>
	<nad-11CAEA.15372607042011@news.gmane.org>
	<4D9E43A7.4000901@noaa.gov>
Message-ID: <72735.1302242295@parc.com>

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

> I'm a bit confused, Bill. You're just that kind of guy that shouldn't
> have any problem hacking your .bash_profile! i.e. you are not the
> target audience for the installer.

Right, I usually just build from source with a non-Framework build if I
need a different Python on OS X.  I just thought I'd try the easy way
this one time.

> Also: I'm pretty sure it's Apple's fault that a de-installer is not a
> easy and obvious part of a .mpg bundle. I don't think I've ever seen
> one with a uninstaller, as a matter of fact.

The package management on Macs leaves something to be desired, to be sure.

Bill

From wardefar at iro.umontreal.ca  Sat Apr  9 05:26:39 2011
From: wardefar at iro.umontreal.ca (David Warde-Farley)
Date: Fri, 8 Apr 2011 23:26:39 -0400
Subject: [Pythonmac-SIG] Python 3. OS/X 10.6 Ipython
In-Reply-To: <4C0004C7.3080401@verizon.net>
References: <4C0004C7.3080401@verizon.net>
Message-ID: <DC9B9872-93E8-4DD4-988B-41A3A9C8B056@iro.umontreal.ca>

IPython stable does not support Python 3. There is an experimental version at http://github.com/ipython/ipython-py3k based off of trunk.

On 2010-05-28, at 2:00 PM, John Riordan wrote:

> I am trying to get IPython running with Python 3.1 on OS/X 10.6.3.
> The install script for IPython configures it to run with Python 2.6.
> Is there a way around this?
> _______________________________________________
> 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 dialtone at gmail.com  Sun Apr 10 07:23:04 2011
From: dialtone at gmail.com (Valentino Volonghi)
Date: Sat, 9 Apr 2011 22:23:04 -0700
Subject: [Pythonmac-SIG] Trouble with NSWindowController
Message-ID: <9D7B6A98-BE53-45E9-8EBD-3EB856D9A44C@gmail.com>

Hi,

I'm using Mac OSX 1.6.8 with XCode4, built-in python and PyObjC and I'm trying to use NSWindowController.

My application is an agent application (no dock, no menu, only a statusbar item with menu).

When somebody presses "preferences" from the menu I bring up a preferences window located in a separate nib file named "Preferences.xib".

At the bottom of this email is the code I'm referring to.

My problem is that NSWindowController.window() always returns None.
Regardless if in InterfaceBuilder I've setup an object that points to PrefsController with the proper outlets and such.

self.window seems to be a native_selector and the call to it succeeds because isWindowLoaded works as expected and showWindow actually displays the window.

I thought it could be a problem with ownership but self.owner() is actually self.

Is there something I'm missing? I've read a couple of examples but they don't seem to be doing anything special about this, it just works.

In the delegate I have:

import preferences

class binderAppDelegate(NSObject):
    preferences = None

    def awakeFromNib(self):
        # snip some code
        self.preferences = preferences.PrefsController("Preferences")

    @objc.IBAction
    def openPreferences_(self, sender):
        NSLog("openPreferences was called.")
        self.preferences.display()


And preferences.py is this:

from Cocoa import *

class PrefsController(NSWindowController):
    def __new__(cls, nibFile):
        return cls.alloc().initWithWindowNibName_(nibFile)

    @objc.selector
    def display(self):
        NSLog("display got called %s" % (self.isWindowLoaded(),))
        window = self.window()
        NSLog("display got called %s" % (self.isWindowLoaded(),))
        self.showWindow_(self)
        
        self.window().orderFrontRegardless()
        NSApp.activateIgnoringOtherApps_(True)
        return    


-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.6
http://www.adroll.com/


From ckkart at hoc.net  Sun Apr 10 10:06:57 2011
From: ckkart at hoc.net (Christian K.)
Date: Sun, 10 Apr 2011 08:06:57 +0000 (UTC)
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
Message-ID: <loom.20110410T095959-844@post.gmane.org>

Hi,

I tried to make an app using py2app on OSX 10.6.5, python 2.6.5,
wxpython 2.8.11.0
Building works, but when running I get

File "wx/lib/pubsub/pub.pyc", line 24, in <module>
File "wx/lib/pubsub/core/listener.pyc", line 13, in <module>
ImportError: No module named listenerimpl

I had (other) problems with pubsub using py2exe, too, and I needed to add
'wx.lib.pubsub' to the 'package' section of the setup options dict. That did
not help py2app though.

Any ideas?

Regards, Christian



From aahz at pythoncraft.com  Sun Apr 10 22:12:30 2011
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 10 Apr 2011 13:12:30 -0700
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <loom.20110410T095959-844@post.gmane.org>
References: <loom.20110410T095959-844@post.gmane.org>
Message-ID: <20110410201230.GA1694@panix.com>

On Sun, Apr 10, 2011, Christian K. wrote:
>
> I tried to make an app using py2app on OSX 10.6.5, python 2.6.5,
> wxpython 2.8.11.0
> Building works, but when running I get
> 
> File "wx/lib/pubsub/pub.pyc", line 24, in <module>
> File "wx/lib/pubsub/core/listener.pyc", line 13, in <module>
> ImportError: No module named listenerimpl

Do you have this problem with a simple test app?  Are any of your
imports inside ``if`` blocks or function calls?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just        
refer to comments in code as 'lies'. :-)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22

From dialtone at gmail.com  Mon Apr 11 04:23:20 2011
From: dialtone at gmail.com (Valentino Volonghi)
Date: Sun, 10 Apr 2011 19:23:20 -0700
Subject: [Pythonmac-SIG] HotKeys and LaunchServices
Message-ID: <DF49DD25-8C56-4BA9-B97A-719A77985AED@gmail.com>

I've fixed yesterday's problem and it was my fault for not setting the File's Owner in Interface Builder.

My current problem though is different and I don't know how to approach it.

I am trying to do the last 2 bits of the application: start on login and register a global hotkey.

start on login requires LaunchServices and in objective-C it would be a matter of running this:

http://cocoatutorial.grapewave.com/tag/lssharedfilelist-h/

Unfortunately there are 2 problems with that code:

 1) LSSharedFileListRef is not iterable and I don't know how to cast it to (NSArray *) in objective-C or to make it iterable.
 2) kLSSharedFileListItemLast is not exported (this wouldn't be a complex problem if it wasn't for point 1 (I could pass the last item inside the function of course but I'd need to iterate it first).

I tried to use:
_objc.loadBundleVariables(__bundle__, globals(), [('kLSSharedFileListItemLast', '^{OpaqueLSSharedFileListItemRef=}')])

but it segfaults.

Now the second problem is hotkey... That's Carbon API and from the HotKey.py example it would be available under CarbonEvt which is unfortunately absolutely empty while CarbonEvents is not but one without the other is not gonna be very useful.

So without RegisterEventHotKey and UnregisterEventHotKey I don't think I have many chances to do this, at least in Python. I'd need to go the C way and wrap it in a module.

Alternatively is there a way to avoid wrapping in C and instead, just for these 2 cases, and use an ffi method like ctypes?

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.6
http://www.adroll.com/


From ronaldoussoren at mac.com  Mon Apr 11 07:36:26 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 11 Apr 2011 07:36:26 +0200
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
 .bash_profile?
In-Reply-To: <64461.1302209314@parc.com>
References: <64461.1302209314@parc.com>
Message-ID: <DE1EAFC9-B4D9-4FA5-81F7-52AE8AB7297D@mac.com>


On 7 Apr, 2011, at 22:48, Bill Janssen wrote:

> I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
> I'd try Python 2.7 on it.  Normally, I advise people to never try to
> install a different Python on a Mac, as it's too embedded in the OS to
> do safely, without a great deal of domain knowledge.  But here, I
> figured I could always wipe the disk and start over without too much
> loss.
> 
> So I ran the installer, and tried a few things, and it didn't solve my
> buildbot problems.  So I decided to go back to the original System
> python.  But now I find that the installer has put the 2.7 Python on my
> PATH?!?

That's correct, there is an option to disable this behavior. This option is on by default because we had a lot of users that installed Python and then didn't know how to start python because we don't install files in /usr/bin.

>  It does this apparently by hacking ~/.bash_profile.  In there,
> there's a line saying
> 
>  The original version is saved in .bash_profile.pysave

That's odd, the scriptlet that does the work says ($PR is the path to the profile):

if [ -f "${PR}" ]; then
        cp -fp "${PR}" "${PR}.pysave"
fi
echo "" >> "${PR}"
echo "# Setting PATH for Python ${PYVER}" >> "${PR}"
echo "# The orginal version is saved in `basename ${PR}`.pysave" >> "${PR}"
echo 'PATH="'"${PYTHON_ROOT}/bin"':${PATH}"' >> "${PR}"
echo 'export PATH' >> "${PR}"



> 
> a file which doesn't seem to exist.
> 
> So, why didn't I notice myself checking the checkbox to do this in the
> first place, and where is my original .bash_profile file?

The checkbox is on by default.   Did you have a .bash_profile at all? The scriptlet I quoted earlier indicates that the backup is created when the source file exists. 

Ronald

From ronaldoussoren at mac.com  Mon Apr 11 07:44:42 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 11 Apr 2011 07:44:42 +0200
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
 .bash_profile?
In-Reply-To: <rowen-81D53B.15565607042011@news.gmane.org>
References: <64461.1302209314@parc.com>
	<rowen-81D53B.15565607042011@news.gmane.org>
Message-ID: <3B9CCD7B-2DFC-44E7-919E-E7DD35FD5FD4@mac.com>


On 8 Apr, 2011, at 0:56, Russell E. Owen wrote:

> In article <64461.1302209314 at parc.com>, Bill Janssen <janssen at parc.com> 
> wrote:
> 
>> I've got a Snow Leopard buildslave I'm trying to debug.  So I thought
>> I'd try Python 2.7 on it.  Normally, I advise people to never try to
>> install a different Python on a Mac, as it's too embedded in the OS to
>> do safely, without a great deal of domain knowledge.  But here, I
>> figured I could always wipe the disk and start over without too much
>> loss.
>> 
>> So I ran the installer, and tried a few things, and it didn't solve my
>> buildbot problems.  So I decided to go back to the original System
>> python.  But now I find that the installer has put the 2.7 Python on my
>> PATH?!?  It does this apparently by hacking ~/.bash_profile.  In there,
>> there's a line saying
>> 
>>  The original version is saved in .bash_profile.pysave
>> 
>> a file which doesn't seem to exist.
>> 
>> So, why didn't I notice myself checking the checkbox to do this in the
>> first place, and where is my original .bash_profile file?
> 
> I'm surprised you can't find it. I've always had it saved on some 
> obvious place. But I agree that hacking the file is ugly -- it least it 
> could ask.

Feel free to file a bug and attach a patch that does this. 

> 
> In any case you can revert by just deleting the extra lines.
> 
> Other gripes about the installer:
> - It names the version explicitly instead of using the Current symlink 
> (/Libraries/Packages/Python.Package/Versions/Current).

That's intentional, if you install 2.6 with the default settings and 2.7 with the 'update shell profile' section disabled you'd want python 2.6 to be on $PATH while 2.7 shouldn't be. This cannot be done without hardcoding version.

> - It hacks the file even if doesn't need to (e.g. if Current is already 
> on the $PATH then the new python will be found; I think that would be 
> easy to check).

That's a bug, please file a report at bugs.python.org.

> - It adds a bunch of links to /usr/local/bin even though that is 
> redundant with putting Python's bin directory on the $PATH. This makes 
> it a headache to switch Python versions -- something developers often 
> need to do when testing compatibility.

This behavior can be disabled when you run the installer. I agree that the default should be to not install files in /usr/local, although we have had users that complained that the 3.x installers didn't do this.

BTW. I've talked with Ned about this feature at Pycon and we'd like to move to a python-select command that gives you a command-line tool for managing the path to the current python (simular to gcc-select or xcode-select).   That way it should be possible to do away with automaticly patching the shell profile.

Ronald

From ronaldoussoren at mac.com  Mon Apr 11 08:08:53 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 11 Apr 2011 08:08:53 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <loom.20110410T095959-844@post.gmane.org>
References: <loom.20110410T095959-844@post.gmane.org>
Message-ID: <6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>


On 10 Apr, 2011, at 10:06, Christian K. wrote:

> Hi,
> 
> I tried to make an app using py2app on OSX 10.6.5, python 2.6.5,
> wxpython 2.8.11.0
> Building works, but when running I get
> 
> File "wx/lib/pubsub/pub.pyc", line 24, in <module>
> File "wx/lib/pubsub/core/listener.pyc", line 13, in <module>
> ImportError: No module named listenerimpl
> 
> I had (other) problems with pubsub using py2exe, too, and I needed to add
> 'wx.lib.pubsub' to the 'package' section of the setup options dict. That did
> not help py2app though.
> 
> Any ideas?

Adding "includes=['wx.lib.pubsub']" could help.

Ronald
> 
> Regards, Christian
> 
> 
> _______________________________________________
> 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 janssen at parc.com  Mon Apr 11 17:13:45 2011
From: janssen at parc.com (Bill Janssen)
Date: Mon, 11 Apr 2011 08:13:45 PDT
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
	.bash_profile?
In-Reply-To: <3B9CCD7B-2DFC-44E7-919E-E7DD35FD5FD4@mac.com>
References: <64461.1302209314@parc.com>
	<rowen-81D53B.15565607042011@news.gmane.org>
	<3B9CCD7B-2DFC-44E7-919E-E7DD35FD5FD4@mac.com>
Message-ID: <16772.1302534825@parc.com>

Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> BTW. I've talked with Ned about this feature at Pycon and we'd like to
> move to a python-select command that gives you a command-line tool for
> managing the path to the current python (simular to gcc-select or
> xcode-select).  That way it should be possible to do away with
> automaticly patching the shell profile.

How about a Preference Pane?  I could probably remember how to code one
up with PyObjC and Python.

Bill

From ronaldoussoren at mac.com  Mon Apr 11 19:06:14 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 11 Apr 2011 19:06:14 +0200
Subject: [Pythonmac-SIG] why does the Mac installer hack the user's
 .bash_profile?
In-Reply-To: <16772.1302534825@parc.com>
References: <64461.1302209314@parc.com>
	<rowen-81D53B.15565607042011@news.gmane.org>
	<3B9CCD7B-2DFC-44E7-919E-E7DD35FD5FD4@mac.com>
	<16772.1302534825@parc.com>
Message-ID: <1C5C6144-27E3-4589-90D7-F730919A590A@mac.com>


On 11 Apr, 2011, at 17:13, Bill Janssen wrote:

> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
>> BTW. I've talked with Ned about this feature at Pycon and we'd like to
>> move to a python-select command that gives you a command-line tool for
>> managing the path to the current python (simular to gcc-select or
>> xcode-select).  That way it should be possible to do away with
>> automaticly patching the shell profile.
> 
> How about a Preference Pane?  I could probably remember how to code one
> up with PyObjC and Python.

A preference pane would work as well. It would need to be writting in Objective-C though, both because PyObjC is not part of the stdlib and because PyObjC plugins are not (and cannot be) isolated from each other very well. 

I'd prefer to have a solution that works from the command-line as well (for power-users and for integration with other tools)

Ronald


From ckkart at hoc.net  Mon Apr 11 21:11:29 2011
From: ckkart at hoc.net (Christian K.)
Date: Mon, 11 Apr 2011 21:11:29 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>
References: <loom.20110410T095959-844@post.gmane.org>
	<6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>
Message-ID: <invjp1$503$1@dough.gmane.org>

Am 11.04.11 08:08, schrieb Ronald Oussoren:
>
> On 10 Apr, 2011, at 10:06, Christian K. wrote:

>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>> ImportError: No module named listenerimpl
>>
>> I had (other) problems with pubsub using py2exe, too, and I needed to add
>> 'wx.lib.pubsub' to the 'package' section of the setup options dict. That did
>> not help py2app though.
>>
>> Any ideas?
>
> Adding "includes=['wx.lib.pubsub']" could help.


Thanks, but that did not change anything.

Christian


From ckkart at hoc.net  Mon Apr 11 21:12:13 2011
From: ckkart at hoc.net (Christian K.)
Date: Mon, 11 Apr 2011 21:12:13 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <20110410201230.GA1694@panix.com>
References: <loom.20110410T095959-844@post.gmane.org>
	<20110410201230.GA1694@panix.com>
Message-ID: <invjqd$503$2@dough.gmane.org>

Am 10.04.11 22:12, schrieb Aahz:
> On Sun, Apr 10, 2011, Christian K. wrote:
>>
>> I tried to make an app using py2app on OSX 10.6.5, python 2.6.5,
>> wxpython 2.8.11.0
>> Building works, but when running I get
>>
>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>> ImportError: No module named listenerimpl
>
> Do you have this problem with a simple test app?  Are any of your
> imports inside ``if`` blocks or function calls?

No, I import it like this:

from wx.lib.pubsub import setuparg1
from wx.lib.pubsub import pub as Publisher

The first line is important for freezing with py2exe on windows.

Christian



From ckkart at hoc.net  Mon Apr 11 22:29:38 2011
From: ckkart at hoc.net (Christian K.)
Date: Mon, 11 Apr 2011 22:29:38 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <invjp1$503$1@dough.gmane.org>
References: <loom.20110410T095959-844@post.gmane.org>	<6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>
	<invjp1$503$1@dough.gmane.org>
Message-ID: <invobi$18s$1@dough.gmane.org>

Am 11.04.11 21:11, schrieb Christian K.:
> Am 11.04.11 08:08, schrieb Ronald Oussoren:
>>
>> On 10 Apr, 2011, at 10:06, Christian K. wrote:
>
>>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>>> ImportError: No module named listenerimpl
>>>
>>> I had (other) problems with pubsub using py2exe, too, and I needed to
>>> add
>>> 'wx.lib.pubsub' to the 'package' section of the setup options dict.
>>> That did
>>> not help py2app though.
>>>
>>> Any ideas?
>>
>> Adding "includes=['wx.lib.pubsub']" could help.
>
>
> Thanks, but that did not change anything.

I got one step further by adding

'includes':['wx.lib.pubsub.core.kwargs.*','wx.lib.pubsub.core.*']

then I unzipped site-packages.zip and copied the contents of
wx.lib.pubsub.core.kwargs to wx.lib.pubsub.core

and now I get:

File "wx/_gdi.pyc", line 3753, in GetTextExtent
wx._core.PyAssertionError: C++ assertion "Ok()" failed at 
/BUILD/wxPython-src-2.8.11.0/src/common/dcgraph.cpp(880) in 
DoGetTextExtent(): wxGCDC(cg)::DoGetTextExtent - invalid DC

Any ideas?

Christian


From ronaldoussoren at mac.com  Tue Apr 12 17:27:54 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 12 Apr 2011 17:27:54 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <invobi$18s$1@dough.gmane.org>
References: <loom.20110410T095959-844@post.gmane.org>
	<6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>
	<invjp1$503$1@dough.gmane.org> <invobi$18s$1@dough.gmane.org>
Message-ID: <B21AB5D1-C720-480C-B9F7-66CA81907E27@mac.com>


On 11 Apr, 2011, at 22:29, Christian K. wrote:

> Am 11.04.11 21:11, schrieb Christian K.:
>> Am 11.04.11 08:08, schrieb Ronald Oussoren:
>>> 
>>> On 10 Apr, 2011, at 10:06, Christian K. wrote:
>> 
>>>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>>>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>>>> ImportError: No module named listenerimpl
>>>> 
>>>> I had (other) problems with pubsub using py2exe, too, and I needed to
>>>> add
>>>> 'wx.lib.pubsub' to the 'package' section of the setup options dict.
>>>> That did
>>>> not help py2app though.
>>>> 
>>>> Any ideas?
>>> 
>>> Adding "includes=['wx.lib.pubsub']" could help.
>> 
>> 
>> Thanks, but that did not change anything.
> 
> I got one step further by adding
> 
> 'includes':['wx.lib.pubsub.core.kwargs.*','wx.lib.pubsub.core.*']
> 
> then I unzipped site-packages.zip and copied the contents of
> wx.lib.pubsub.core.kwargs to wx.lib.pubsub.core
> 
> and now I get:
> 
> File "wx/_gdi.pyc", line 3753, in GetTextExtent
> wx._core.PyAssertionError: C++ assertion "Ok()" failed at /BUILD/wxPython-src-2.8.11.0/src/common/dcgraph.cpp(880) in DoGetTextExtent(): wxGCDC(cg)::DoGetTextExtent - invalid DC

Could you create a small program that demonstrates the problem?  

Ronald

> 
> Any ideas?
> 
> Christian
> 
> _______________________________________________
> 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 ckkart at hoc.net  Wed Apr 13 20:22:03 2011
From: ckkart at hoc.net (Christian K.)
Date: Wed, 13 Apr 2011 20:22:03 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <B21AB5D1-C720-480C-B9F7-66CA81907E27@mac.com>
References: <loom.20110410T095959-844@post.gmane.org>	<6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>	<invjp1$503$1@dough.gmane.org>
	<invobi$18s$1@dough.gmane.org>
	<B21AB5D1-C720-480C-B9F7-66CA81907E27@mac.com>
Message-ID: <io4pkb$ktv$1@dough.gmane.org>

Am 12.04.11 17:27, schrieb Ronald Oussoren:
>
> On 11 Apr, 2011, at 22:29, Christian K. wrote:
>
>> Am 11.04.11 21:11, schrieb Christian K.:
>>> Am 11.04.11 08:08, schrieb Ronald Oussoren:
>>>>
>>>> On 10 Apr, 2011, at 10:06, Christian K. wrote:
>>>
>>>>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>>>>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>>>>> ImportError: No module named listenerimpl
>>>>>
>>>>> I had (other) problems with pubsub using py2exe, too, and I needed to
>>>>> add
>>>>> 'wx.lib.pubsub' to the 'package' section of the setup options dict.
>>>>> That did
>>>>> not help py2app though.
>>>>>
>>>>> Any ideas?
>>>>
>>>> Adding "includes=['wx.lib.pubsub']" could help.
>>>
>>>
>>> Thanks, but that did not change anything.
>>
>> I got one step further by adding
>>
>> 'includes':['wx.lib.pubsub.core.kwargs.*','wx.lib.pubsub.core.*']
>>
>> then I unzipped site-packages.zip and copied the contents of
>> wx.lib.pubsub.core.kwargs to wx.lib.pubsub.core
>>
>> and now I get:
>>
>> File "wx/_gdi.pyc", line 3753, in GetTextExtent
>> wx._core.PyAssertionError: C++ assertion "Ok()" failed at /BUILD/wxPython-src-2.8.11.0/src/common/dcgraph.cpp(880) in DoGetTextExtent(): wxGCDC(cg)::DoGetTextExtent - invalid DC
>
> Could you create a small program that demonstrates the problem?

Well, I found out (from the wxwidgets mailing-list) that this is related 
to not attaching a Bitmap to a MemoryDC, which I did though and the 
script runs from 'source', but I took that part out and the script 
crashes heavily some steps later. Which in the end brought me to stop 
trying to make an app.
Thanks anyway.

Christian



From daniel at phasevelocity.org  Tue Apr 12 06:32:33 2011
From: daniel at phasevelocity.org (Daniel Rogers)
Date: Mon, 11 Apr 2011 21:32:33 -0700
Subject: [Pythonmac-SIG] py2app wierdness
Message-ID: <914198f1e1e47aacdd0e100e393050a3@phasevelocity.org>


Hi,

I installed py2app with easy_install, using the system python on Mac OS X.
Now when I try to build a .app that needs additional data directories,
those additional data directories are not being copied to the application
bundle.

For example,  I have a directory "fonts"

Regardless of if I add ['fonts'] as the value of "data_files" in the call
to setup.py, or add 'fonts' as the value of 'resources' in the OPTIONS
dict, "fonts" is not being copied to Contents/Resources and my application
fails to startup correctly.  If I copy the directory to the resources path
my hand the application will start normally.

Does the "data_files" option supposed work?  For all that I can tell, it
doesn't work for the 'pygame' example either.

-- 
Daniel

From ronaldoussoren at mac.com  Thu Apr 14 11:09:53 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Apr 2011 11:09:53 +0200
Subject: [Pythonmac-SIG] py2app wierdness
In-Reply-To: <914198f1e1e47aacdd0e100e393050a3@phasevelocity.org>
References: <914198f1e1e47aacdd0e100e393050a3@phasevelocity.org>
Message-ID: <57825244-2CC3-43A2-A4D2-34AB18C276EB@mac.com>


On 12 Apr, 2011, at 6:32, Daniel Rogers wrote:

> 
> Hi,
> 
> I installed py2app with easy_install, using the system python on Mac OS X.
> Now when I try to build a .app that needs additional data directories,
> those additional data directories are not being copied to the application
> bundle.
> 
> For example,  I have a directory "fonts"
> 
> Regardless of if I add ['fonts'] as the value of "data_files" in the call
> to setup.py, or add 'fonts' as the value of 'resources' in the OPTIONS
> dict, "fonts" is not being copied to Contents/Resources and my application
> fails to startup correctly.  If I copy the directory to the resources path
> my hand the application will start normally.
> 
> Does the "data_files" option supposed work?  For all that I can tell, it
> doesn't work for the 'pygame' example either.

It is supposed to work, but probably broke due to some other changes. I'll look into this and will add a testcase that tests this option. 

Py2app at this time doesn't have very good test coverage, although that's improving as I'm adding new tests whenever I make changes to the code base.

Ronald


From ronaldoussoren at mac.com  Thu Apr 14 11:48:12 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Apr 2011 11:48:12 +0200
Subject: [Pythonmac-SIG] py2app + wxpython -> ImportError
In-Reply-To: <io4pkb$ktv$1@dough.gmane.org>
References: <loom.20110410T095959-844@post.gmane.org>
	<6FC97B10-56EE-41DC-9DBC-06ABBF91B604@mac.com>
	<invjp1$503$1@dough.gmane.org> <invobi$18s$1@dough.gmane.org>
	<B21AB5D1-C720-480C-B9F7-66CA81907E27@mac.com>
	<io4pkb$ktv$1@dough.gmane.org>
Message-ID: <C2D5FEBF-E687-40A9-BD24-83944A12A793@mac.com>


On 13 Apr, 2011, at 20:22, Christian K. wrote:

> Am 12.04.11 17:27, schrieb Ronald Oussoren:
>> 
>> On 11 Apr, 2011, at 22:29, Christian K. wrote:
>> 
>>> Am 11.04.11 21:11, schrieb Christian K.:
>>>> Am 11.04.11 08:08, schrieb Ronald Oussoren:
>>>>> 
>>>>> On 10 Apr, 2011, at 10:06, Christian K. wrote:
>>>> 
>>>>>> File "wx/lib/pubsub/pub.pyc", line 24, in<module>
>>>>>> File "wx/lib/pubsub/core/listener.pyc", line 13, in<module>
>>>>>> ImportError: No module named listenerimpl
>>>>>> 
>>>>>> I had (other) problems with pubsub using py2exe, too, and I needed to
>>>>>> add
>>>>>> 'wx.lib.pubsub' to the 'package' section of the setup options dict.
>>>>>> That did
>>>>>> not help py2app though.
>>>>>> 
>>>>>> Any ideas?
>>>>> 
>>>>> Adding "includes=['wx.lib.pubsub']" could help.
>>>> 
>>>> 
>>>> Thanks, but that did not change anything.
>>> 
>>> I got one step further by adding
>>> 
>>> 'includes':['wx.lib.pubsub.core.kwargs.*','wx.lib.pubsub.core.*']
>>> 
>>> then I unzipped site-packages.zip and copied the contents of
>>> wx.lib.pubsub.core.kwargs to wx.lib.pubsub.core
>>> 
>>> and now I get:
>>> 
>>> File "wx/_gdi.pyc", line 3753, in GetTextExtent
>>> wx._core.PyAssertionError: C++ assertion "Ok()" failed at /BUILD/wxPython-src-2.8.11.0/src/common/dcgraph.cpp(880) in DoGetTextExtent(): wxGCDC(cg)::DoGetTextExtent - invalid DC
>> 
>> Could you create a small program that demonstrates the problem?
> 
> Well, I found out (from the wxwidgets mailing-list) that this is related to not attaching a Bitmap to a MemoryDC, which I did though and the script runs from 'source', but I took that part out and the script crashes heavily some steps later.

This indicates that not everything that's needed is included in the app bundle. I won't be able to fix the issue without an example that demonstrates the problem, and sadly enough don't have time to create such an example myself (as I've stopped using wx myself and hadn't even heard of wx.lib.pubsub before your initial e-mail).

Ronald


> Which in the end brought me to stop trying to make an app.
> Thanks anyway.
> 
> Christian
> 
> 
> _______________________________________________
> 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  Fri Apr 15 06:00:07 2011
From: kw at codebykevin.com (Kevin Walzer)
Date: Fri, 15 Apr 2011 00:00:07 -0400
Subject: [Pythonmac-SIG] Tkinter app in Mac App Store
Message-ID: <4DA7C2C7.3020404@codebykevin.com>

Hi all,

I'm just writing to mention that I've had a Tkinter app approved in the 
Mac App Store, QuickWho (http://www.codebykevin.com/quickwho.html). I'm 
pretty sure it's not the first Python app included in the App Store (I 
believe there are a few PyObjC apps there), but there has been little 
discussion of the App Store on this list, so I wanted to share a few 
experiences, in case anyone is planning to submit a Tkinter-based 
program to the App Store.

Most of my challenges revolved around the fact that Tk-Cocoa uses 
numerous calls into private methods and API's (or SPI, I guess), and so 
you can't bundle the Tcl/Tk frameworks with your application. The 
workaround for this is to link your application to the Tcl/Tk Cocoa 
frameworks that are bundled with OS X in /System/Library. As has been 
well-documented, this build of Tk is rather buggy, so proceed with caution.

Using this approach requires a custom build of Python that links to the 
frameworks in /System/Library rather than in /Library; the simplest way 
to make sure of this is to move other installations of Tcl/Tk in 
/Library/Frameworks to another location.

I outline some details about this in more depth here: 
http://www.codebykevin.com/opensource/app-store.html. This article 
doesn't mention Python (it focuses instead on Tk), but most of it is 
applicable, and can be supplemented by what I've outlined in this e-mail.

Hope others find this useful,
Kevin

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

From georg.seifert at gmx.de  Tue Apr 19 11:40:32 2011
From: georg.seifert at gmx.de (Georg Seifert)
Date: Tue, 19 Apr 2011 11:40:32 +0200
Subject: [Pythonmac-SIG] custom framework with bridgesupport file
Message-ID: <528702D3-E2B7-4991-A597-FC6583FF2630@gmx.de>

Hi,

I have an app written in cocoa and run python scripts from within the app using "PyRun_SimpleString" (I asked about that a couple of times and got great help).

My problem now is that I want to use some c functions from within a custom framework that is embedded in my app. The only way I could get it to work is to load the bridgesupport file manually:

_path = objc.pathForFramework('../Frameworks/MyFramework.framework')
f = open(_path+'/Versions/A/Resources/BridgeSupport/MyFramework.bridgesupport')
objc.parseBridgeSupport(f.read(), globals(), _path+'/Versions/A/Resources/BridgeSupport/MyFramework.bridgesupport')
f.close()

I have to put this in the script for every run. Is there a better way to tell python to pick the file up automatically?

Best
Georg

From ronaldoussoren at mac.com  Tue Apr 19 13:27:47 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 19 Apr 2011 13:27:47 +0200
Subject: [Pythonmac-SIG] custom framework with bridgesupport file
In-Reply-To: <528702D3-E2B7-4991-A597-FC6583FF2630@gmx.de>
References: <528702D3-E2B7-4991-A597-FC6583FF2630@gmx.de>
Message-ID: <98C04AA3-7A64-4499-AB0A-E176E2D4B38E@mac.com>


On 19 Apr, 2011, at 11:40, Georg Seifert wrote:

> Hi,
> 
> I have an app written in cocoa and run python scripts from within the app using "PyRun_SimpleString" (I asked about that a couple of times and got great help).
> 
> My problem now is that I want to use some c functions from within a custom framework that is embedded in my app. The only way I could get it to work is to load the bridgesupport file manually:
> 
> _path = objc.pathForFramework('../Frameworks/MyFramework.framework')
> f = open(_path+'/Versions/A/Resources/BridgeSupport/MyFramework.bridgesupport')
> objc.parseBridgeSupport(f.read(), globals(), _path+'/Versions/A/Resources/BridgeSupport/MyFramework.bridgesupport')
> f.close()
> 
> I have to put this in the script for every run. Is there a better way to tell python to pick the file up automatically?

You will always have to do something to load the bridgesupport data.  You might be able to use "objc.initFrameworkWrapper", that function will load the embedded bridgesupport file. This function is usually used to also load the framework, but when you specify the framework identifier it wouldn't do that when the framework is already loaded.

Ronald


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/20110419/77a91b77/attachment.bin>

From lou_boog2000 at yahoo.com  Tue Apr 19 19:11:18 2011
From: lou_boog2000 at yahoo.com (Lou Pecora)
Date: Tue, 19 Apr 2011 10:11:18 -0700 (PDT)
Subject: [Pythonmac-SIG]   Is this a reasonable way to do multiprocessing?
Message-ID: <147365.45084.qm@web34403.mail.mud.yahoo.com>

I have a calculation which runs via a method of a class.  It is trivially 
parallelizable.  The method is just called over and over with different 
arguments. No communication, synchronization, or cooperation is needed between 
the function calls. But it is highly computational and I want to speed it all 
up.  I discovered the multiprocessing module and the use of Pool.  So my thought 
was to do something like this,

import multiprocessing as MP
class mainclass(object):
def aMethod(x):
# do stuff with x
return result
myclass=mainclass()
pool= MP.Pool(processes= 3)  # 3 CPU workers, for example
theargs= [x1,x2,x3]
resultlist= pool.map(myclass.aMethod, thargs)

But as many of you probably know that raises a pickle error.  I did a little 
research and don't fully understand, but I thought of a way around this that is 
pedestrian, but it works on my toy example. I just make (deep) copies of my 
object and let a helper function call mainclass'  aMethod. So I change the code 
(after my class definition) to,

import copy
def helperFunc(a):
return a[0].aMethod(a[1])
myclass=mainclass()
pool= MP.Pool(processes= 3)  # 3 CPU workers
theargs= [[copy.deepcopy(myclass),x1],[copy.deepcopy(myclass),x2], \
[copy.deepcopy(myclass),x3]]
resultlist= pool.map(helperFunc, thargs)

My question (subject of this post):  Is this reasonable?  Not whether it's the 
best or most efficient, but does it go most of the way in this situation to give 
me much more speedup?

Further question, on an 8 CPU MacBook Pro I get a 4X speedup (with 8 CPU 
workers), not 8X (Activity Monitor shows all 8 CPUs are utilized ~100%).  Is 
there something about dual core processors that I should know about? (since 4 = 
8/2).  

Thanks for any pointers or info. -- Lou Pecora,   my views are my own.


From nathaniel.echols at gmail.com  Tue Apr 19 19:39:27 2011
From: nathaniel.echols at gmail.com (Nat Echols)
Date: Tue, 19 Apr 2011 10:39:27 -0700
Subject: [Pythonmac-SIG] Is this a reasonable way to do multiprocessing?
In-Reply-To: <147365.45084.qm@web34403.mail.mud.yahoo.com>
References: <147365.45084.qm@web34403.mail.mud.yahoo.com>
Message-ID: <BANLkTi=wpRC5eZUN0vtMfB__C62=iNACDA@mail.gmail.com>

On Tue, Apr 19, 2011 at 10:11 AM, Lou Pecora <lou_boog2000 at yahoo.com> wrote:

> But as many of you probably know that raises a pickle error.  I did a
> little
> research and don't fully understand, but I thought of a way around this
> that is
> pedestrian, but it works on my toy example. I just make (deep) copies of my
> object and let a helper function call mainclass'  aMethod. So I change the
> code

(after my class definition) to,
>

This is overkill.  I don't understand the precise technical explanation for
the error, but I think it just means that you can't pickle an object's
method - only the object itself (assuming it doesn't have features that
break pickling).  So what I do is this:

import multiprocessing as MP
class mainclass (object) :
  def __call__ (self, x) :
     # do something
     return result

myclass=mainclass()
pool= MP.Pool(processes= 3)  # 3 CPU workers, for example
theargs= [x1,x2,x3]
resultlist= pool.map(myclass, thargs)

The only time I use a helper function like what you describe is when the
iterable objects contain both the method of interest and the arguments,
e.g.:

class mainclass (object):
  def __init__ (self, x) :
     self.x = x

  def run (self) :
     return x**2

def run_many (obj) :
  return obj.run()

args = []
for x in [13,29,71] :
   args.append(mainclass(x))
p = MP.Pool(processes=3)
p.map(run_many, args)

Which version to use is very case-dependent - my code has both.

Further question, on an 8 CPU MacBook Pro I get a 4X speedup (with 8 CPU
> workers), not 8X (Activity Monitor shows all 8 CPUs are utilized ~100%).
>  Is
> there something about dual core processors that I should know about? (since
> 4 =
> 8/2).
>

The top-of-the-line MacBook Pro only has 4 cores - I think you're confusing
Intel's "hyper-threading" with actual cores (not surprising, since software
tends to confuse them too, e.g. Linux kernel).  You are very unlikely to see
a significant speedup using 8 processes versus 4 with the kind of crude
parallelization implemented in the Python multiprocessing module.  (I assume
that lower-level threading tools like OpenMP will use hyperthreading more
efficiently, but I've never tested this.)

-Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110419/b9954e12/attachment.html>

From lou_boog2000 at yahoo.com  Tue Apr 19 19:48:21 2011
From: lou_boog2000 at yahoo.com (Lou Pecora)
Date: Tue, 19 Apr 2011 10:48:21 -0700 (PDT)
Subject: [Pythonmac-SIG] Is this a reasonable way to do multiprocessing?
In-Reply-To: <BANLkTi=wpRC5eZUN0vtMfB__C62=iNACDA@mail.gmail.com>
References: <147365.45084.qm@web34403.mail.mud.yahoo.com>
	<BANLkTi=wpRC5eZUN0vtMfB__C62=iNACDA@mail.gmail.com>
Message-ID: <485338.71658.qm@web34403.mail.mud.yahoo.com>

From: Nat Echols <nathaniel.echols at gmail.com>
To: Lou Pecora <lou_boog2000 at yahoo.com>
Cc: pythonmac-sig at python.org
Sent: Tue, April 19, 2011 1:39:27 PM
Subject: Re: [Pythonmac-SIG] Is this a reasonable way to do multiprocessing?

On Tue, Apr 19, 2011 at 10:11 AM, Lou Pecora <lou_boog2000 at yahoo.com> wrote:

But as many of you probably know that raises a pickle error.  I did a little
>research and don't fully understand, but I thought of a way around this that is
>pedestrian, but it works on my toy example. I just make (deep) copies of my
>object and let a helper function call mainclass'  aMethod. So I change the 
code 
(after my class definition) to,
>

This is overkill.  I don't understand the precise technical explanation for the 
error, but I think it just means that you can't pickle an object's method - only 
the object itself (assuming it doesn't have features that break pickling).  So 
what I do is this:

import multiprocessing as MP

class mainclass (object) :
  def __call__ (self, x) :
     # do something
     return result

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

I see, you use the __call__ function.  Forgot completely about that.  I think I 
could change my class to handle that.  I'll try it.  Thanks very much.  And 
thanks for the info on cores and CPUs.  I also have a 12 core Mac Pro so I can 
get some speed up on that.

And my apologies to all for the bad formatting of the code in my message.  I 
should have replaced tabs with spaces.

-- Lou Pecora, my views are my own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20110419/7aa8b191/attachment-0001.html>

From orien.madgwick at gmail.com  Sun Apr 24 00:17:44 2011
From: orien.madgwick at gmail.com (Orien Madgwick)
Date: Sun, 24 Apr 2011 08:17:44 +1000
Subject: [Pythonmac-SIG] Compiling xib files with py2app
Message-ID: <4580B9E3-2339-4498-8B40-46141E5D2CFF@gmail.com>

Hi,
I'm having difficulty compiling xib files when packaging a python  
application with py2app 0.6.2. I haven't been able to find any  
documentation on how this should work but my expectation is that if I  
declare the xib file in the data_files section of my setup.py then it  
should be converted to a nib file and included in the application  
package. Is this a correct expectation? The behaviour I'm seeing is  
the xib file is simply copied to the application package without  
processing. Any help on the correct way to approach this would be great.

--
Orien

From ronaldoussoren at mac.com  Mon Apr 25 13:13:03 2011
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 25 Apr 2011 13:13:03 +0200
Subject: [Pythonmac-SIG] Compiling xib files with py2app
In-Reply-To: <4580B9E3-2339-4498-8B40-46141E5D2CFF@gmail.com>
References: <4580B9E3-2339-4498-8B40-46141E5D2CFF@gmail.com>
Message-ID: <B8817CA8-D319-468E-BBCD-AD199071733F@mac.com>


On 24 Apr, 2011, at 0:17, Orien Madgwick wrote:

> Hi,
> I'm having difficulty compiling xib files when packaging a python application with py2app 0.6.2. I haven't been able to find any documentation on how this should work but my expectation is that if I declare the xib file in the data_files section of my setup.py then it should be converted to a nib file and included in the application package. Is this a correct expectation? The behaviour I'm seeing is the xib file is simply copied to the application package without processing. Any help on the correct way to approach this would be great.

That's a bug. I've just uploaded py2app 0.6.3 which includes a fix for this bug.

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/20110425/5b4091fb/attachment.bin>

From lou_boog2000 at yahoo.com  Thu Apr 28 17:44:11 2011
From: lou_boog2000 at yahoo.com (Lou Pecora)
Date: Thu, 28 Apr 2011 08:44:11 -0700 (PDT)
Subject: [Pythonmac-SIG]   Deepcopy failure.  How to find what failed?
Message-ID: <586020.42228.qm@web34404.mail.mud.yahoo.com>

I am trying to make a Deepcopy of an object with several objects as data.  I get 
an error "instancemethod expected at least 2 arguments, got 0" (complete error 
message below -- sorry, it's long one), but I have no idea what that refers to 
or what is failing. Is there a way to tell what is failing to Deepcopy?  

 
More info: I tried Deepcopy on some of the data objects in my original object 
instance and they all got copied without errors.  So it is something else in my 
original object, but I cannot get very far given the error messages.
 
I also tried to use Pool and Pool.map on this object (I'm trying to use 
multiprocess module, but let's keep things simple for now).  The latter failed, 
giving a pickle error.  I suspect it's the same problem.  

 
Any help appreciated.
 
Error Traceback:
 
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
 
/Users/louispecora/calc/Well-Barrier_systems/VDWB2P/VDWB2P_1/drvrVDWB2P_1.py in 
<module>()
    121                         Ei=Erangelist[i];  Ef=Erangelist[i+1];  
nE=nElist[i+1]
    122                         # 0th item tells driverbem which function to 
call in pool.map
 
--> 123                         
args.append([CP.deepcopy(dvrbem),Ei,Ef,nE,prnresF, figdir, prnresF, adaptF, 
mindeldTdE, minStep, maxStep])
    124                 print '\nargs:\n',args
    125                 sys.exit()
 
/Applications/sage-4.6/local/lib/python/copy.pyc in deepcopy(x, memo, _nil)
    187                             raise Error(
    188                                 "un(deep)copyable object of type %s" % 
cls)
--> 189                 y = _reconstruct(x, rv, 1, memo)
    190 
    191     memo[d] = y
 
/Applications/sage-4.6/local/lib/python/copy.pyc in _reconstruct(x, info, deep, 
memo)
    336     if state:
    337         if deep:
--> 338             state = deepcopy(state, memo)
    339         if hasattr(y, '__setstate__'):
    340             y.__setstate__(state)
 
/Applications/sage-4.6/local/lib/python/copy.pyc in deepcopy(x, memo, _nil)
    160     copier = _deepcopy_dispatch.get(cls)
    161     if copier:
--> 162         y = copier(x, memo)
    163     else:
    164         try:
 
/Applications/sage-4.6/local/lib/python/copy.pyc in _deepcopy_dict(x, memo)
    253     memo[id(x)] = y
    254     for key, value in x.iteritems():
--> 255         y[deepcopy(key, memo)] = deepcopy(value, memo)
    256     return y
    257 d[dict] = _deepcopy_dict
 
/Applications/sage-4.6/local/lib/python/copy.pyc in deepcopy(x, memo, _nil)
    160     copier = _deepcopy_dispatch.get(cls)
    161     if copier:
--> 162         y = copier(x, memo)
    163     else:
    164         try:
 
/Applications/sage-4.6/local/lib/python/copy.pyc in _deepcopy_dict(x, memo)
    253     memo[id(x)] = y
    254     for key, value in x.iteritems():
--> 255         y[deepcopy(key, memo)] = deepcopy(value, memo)
    256     return y
    257 d[dict] = _deepcopy_dict
 
/Applications/sage-4.6/local/lib/python/copy.pyc in deepcopy(x, memo, _nil)
    187                             raise Error(
    188                                 "un(deep)copyable object of type %s" % 
cls)
--> 189                 y = _reconstruct(x, rv, 1, memo)
    190 
    191     memo[d] = y
 
/Applications/sage-4.6/local/lib/python/copy.pyc in _reconstruct(x, info, deep, 
memo)
    321     if deep:
    322         args = deepcopy(args, memo)
--> 323     y = callable(*args)
    324     memo[id(x)] = y
    325     if listiter is not None:
 
/Applications/sage-4.6/local/lib/python/copy_reg.pyc in __newobj__(cls, *args)
     91 
     92 def __newobj__(cls, *args):
---> 93     return cls.__new__(cls, *args)
     94 
     95 def _slotnames(cls):
 
TypeError: instancemethod expected at least 2 arguments, got 0
logout -- Lou Pecora,   my views are my own.