Re: [Pythonmac-SIG] Trouble building tkinter for Aqua

[Ned Deily]

On Dec 7, 2023, at 17:18, Matthew Dixon Cowles  wrote:
> I'm trying to compile Python 3.12.0 from source on a new ARM MacBook.
> I haven't had any trouble except with the tkinter module. I've built
> Python from source any number of times before on Linux and macOS, but
> previously always with X11. (For the moment, I'm just doing an
> ordinary Unix build, not a Framework build.) [...]

The process for specifying third-party libs for Python builds changed greatly 
for Python 3.11 and improved a bit in 3.12. It is now much simpler and more 
consistent.

It's pretty much automatic if you have a version of `pkg-config` installed and 
use third-party libraries that install .pc files (most do these days). Apple 
does not ship a version of pkg-config but third-party distributors like 
Homebrew and MacPorts have it (as well as pre-built versions of all other 
needed libraries, including Tk).  It's also easy to build a non-GPL version 
(try https://github.com/pkgconf/pkgconf). In any case you may need to set the 
PKG_CONFIG_PATH env variable to point to the .pc files for your Tcl and Tk. 
There are some potentially useful examples of using Homebrew and MacPorts in 
the Python Developers Guide: 
https://devguide.python.org/getting-started/setup-building/#install-dependencies

But otherwise, rather than modifying the Makefile, use the new ./configure 
options provided to override defaults for the various third-party libraries:

$ ./configure --help

`configure' configures python 3.12 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.
[...]
  TCLTK_CFLAGS
  C compiler flags for TCLTK, overriding pkg-config
  TCLTK_LIBS  linker flags for TCLTK, overriding pkg-config

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Universal build launches as Intel on M1

[Ned Deily]

On 28 Mar 2022, at 10:08, Aivar Annamaa  wrote:
> I have an app bundle, with embedded python.org's universal build of Python 
> 3.10.2 framework and a Tkinter-based GUI 
> (https://github.com/thonny/thonny/releases/tag/v4.0.0b1)
> 
> I've used IDLE's approach in the Info.plist, and the launcher script. 
> Functionally all is working fine, but a M1 user reported, that when opened 
> from Finder, the app is launched in "Intel" mode. When the launcher is 
> invoked in Terminal (/Applications/Thonny.app/Contents/MacOS/thonny), the app 
> gets run in AMD64 mode. I don't have a M1 myself, so I haven't reproduced it 
> myself.
> 
> The same user now said that latest IDLE (3.10.4) runs in AMD64 mode even when 
> launched from Finder.
> 
> Any ideas what to check or try in order to make my app run in native mode?
> 
> My launcher script template is here: 
> https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/MacOS/thonny
>  (shebang becomes gets set to 
> .../Thonny.app/Contents/Frameworks/Python.framework/Versions/3.10/Resources/Python.app/Contents/MacOS/Python
>  by the postinstall script)
> 
> Info.plist template is here: 
> https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/Info.plist


It looks the problem is in your Distribution.plist; change the 
hostArchitectures to "arm64,x86_64".  Otherwise, the macOS installer assumes 
your app can only run as an Intel binary.

https://github.com/thonny/thonny/blob/a9d12ba961eac875dc4a77ac1fb226baf5c3acc9/packaging/mac/Distribution.plist#L9

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Hi. I am having difficulty installing NLTK on my Mac (12.02.01). Is there anyone who can help?

[Ned Deily]

On Mar 7, 2022, at 14:58, Robert Wasserman  wrote:
> Thank you so much for responding to my email.   I’ve spent hours and searched 
> for other forms of the instructions for using NLTK,

You're welcome but, in the future, please reply to the mailing list so that 
everyone can participate and benefit. I've CC-ed this reply.

> Under the lines that loaded Python 10.3.1   Python 10.3.1 Header, I got the 
> >>>  prompt and I assumed that I could continue with in Python3 by typing 
> Python or Python3 but neither worked
>  and  the  from NLTK.book.import  *  returned the message printed below
>   import NLTK and followed that at the next  >>>  prompt with  NLTK.downoad() 
> 
> 
> But did not get the material in Figure   (the figure headed with Collectcions 
> , Corpora  Models All Packages etc.
> 
> From the >>> prompt  tried.>>>from NLTK.book import *   
> 
> Long ago, I recall having gone through the same process when using Python2.7 
> or perhaps 2.5 and got the data and was able to run Python and then the 
> >>>from NLTK.book import *.
>  
> …and then was able to type the commands such as text1(Moby Dick) and the 
> other texts which I could then use with commands such as 
> >>>text1.concordance(“monstrous”). Etc
> 
> But when I used IDLE  and brought up the Python3  prompt, it seemed that 
> Python3 loaded properly but as not able to act on perform commands.  The 
> command line responded that 
> To my effort to type “from NLTK.book. import *  
> With.Last login: Sun Mar  6 14:49:42 on ttys000
> (base) robertwasserman@Roberts-MacBook-Pro ~ % python
> Python 3.9.7 (default, Sep 16 2021, 08:50:36) 
> [Clang 10.0.0 ] :: Anaconda, Inc. on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from nltk.book.import *
>   File "", line 1
> from nltk.book.import *
>^
> SyntaxError: invalid syntax
> >>> 

The syntax error is from an extra ".". Instead, try:

from nltk.book import *

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Hi. I am having difficulty installing NLTK on my Mac (12.02.01). Is there anyone who can help?

[Ned Deily]

On Mar 3, 2022, at 16:15, Ned Deily  wrote:
> On Feb 27, 2022, at 15:51, Robert Wasserman via Pythonmac-SIG 
>  wrote:
>> 
>> I’ve been learning pylon on my Mac and and am trying to install NLTK so I 
>> can try the examples in the NLTK text.
>> 
>> The instructions in NLTK are straightforward and I am able to get Python 
>> itself on my computer, but I cannot get “pip” to work. 
>> 
>> I would appreciate any help or sources of help.   My problem seems to be 
>> getting Python to work on the data provided in the NLTK.
> 
> Sorry but without more information, it is impossible to provide meaningful 
> help. But the most common problem with using pip is trying to use the wrong 
> version of pip. The best way to avoid that is to invoke pip using the same 
> name you are using to invoke python itself. So, for example, from a Terminal 
> window, if you type "python3" to start up Python, use this:
> 
> python3 -m pip install ntlk

Er, of course, that should be:

python3 -m pip install nltk

> If you are still having problems, please copy and paste the full sequence of 
> commands that you are entering and the error messages you see.
> 
> FWIW, I just tried it with the current Python 3.10.2 macOS installed from 
> python.org and it seemed to work.
> 
> P.S. general Python usage questions are probably more quickly solved via one 
> of the general help forums out there. See https://www.python.org/about/help/.

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Hi. I am having difficulty installing NLTK on my Mac (12.02.01). Is there anyone who can help?

[Ned Deily]

On Feb 27, 2022, at 15:51, Robert Wasserman via Pythonmac-SIG 
 wrote:
> 
> I’ve been learning pylon on my Mac and and am trying to install NLTK so I can 
> try the examples in the NLTK text.
> 
> The instructions in NLTK are straightforward and I am able to get Python 
> itself on my computer, but I cannot get “pip” to work. 
> 
> I would appreciate any help or sources of help.   My problem seems to be 
> getting Python to work on the data provided in the NLTK.

Sorry but without more information, it is impossible to provide meaningful 
help. But the most common problem with using pip is trying to use the wrong 
version of pip. The best way to avoid that is to invoke pip using the same name 
you are using to invoke python itself. So, for example, from a Terminal window, 
if you type "python3" to start up Python, use this:

python3 -m pip install ntlk

If you are still having problems, please copy and paste the full sequence of 
commands that you are entering and the error messages you see.

FWIW, I just tried it with the current Python 3.10.2 macOS installed from 
python.org and it seemed to work.

P.S. general Python usage questions are probably more quickly solved via one of 
the general help forums out there. See https://www.python.org/about/help/.

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Need M1 Mac to Test

[Ned Deily]

On Jan 12, 2022, at 15:53, jack.jan...@cwi.nl wrote:
> Python runs just fine natively on M1 Macs. The python.org installer will 
> install a Universal2 binary (a single binary containing both the i386 and arm 
> architectures).
> 
> If you install through brew you get the architecture your brew has been 
> configured for.
> 
> But there _is_ a problem with native arm Python, and that is that not all 
> extension packages (think: from pypi) have M1 versions available yet. This is 
> especially true for packages that depend on external libraries (which may not 
> have been ported to M1 yet).
> 
> The way I handle this on my (M1) development machine is that I have both 
> versions of brew installed, which is easy because arm-brew installs into 
> /opt/homebrew by default and intel-brew installs into /usr/local.
> 
> If I open a Terminal window it has /opt/homebrew/bin before /usr/local/bin in 
> my $PATH, and the background is white.
> 
> If I open an iTerm window it runs in Rosetta intel emulation mode, it has 
> /usr/local/bin before /opt/homebrew/bin, and the background is a creamy 
> old-fashioned looking off-white color.
> 
> As long as I do builds in the window of the correct color, and the correct 
> tools I need for building have been installed in the correct directory 
> everything works fine.The white windows will use python3 for arm, the cream 
> windows will use python3 for intel.

That is one good solution.

For those using a universal2 (M1 arm64 and Intel-64 x86_64) build like those 
from the python.org installers or built from scratch with 
--with-universal-archs=universal2, 

./configure --enable-universalsdk --with-universal-archs=universal2 
--prefix=[...] or --enable-framework=[...] ...
make -j2 && make install

note that a separate python3{x}-intel64 Intel-only executable is installed 
along with the dual architecture python3{x} executable. In theory it is 
possible to select which architecture a multi-arch executable is to run under 
when there is more than one option by using the "arch" command, like here to 
force running in Intel emulation mode under Rosetta2 on an M1 Mac:

arch -x86_64 /path/to/python3{x}

But there is a big gotcha with that: if anything running under that non-default 
arch Python spins off another Python in a subprocess by using the value of 
sys.executable to find the running interpreter binary, the "arch -x86_64" is 
effectively lost and the interpreter in the subprocess will run in the default 
architecture. This happens, for instance, when running Python's own test suite: 
the top-level Python process running regrtest will be running in Intel 
emulation but tests running in subprocesses will still be running in the 
default arm64 arch, possibly giving errors or silently producing misleading 
results. Running the tests using python3{}-intel64 avoids that problem.

Also note that, as of today, we still don't officially support cross-building 
of single arch Pythons on macOS, that is, building an Intel-only Python on an 
M1 or vice-versa. If you need such a beast, what should work is building a 
universal2 version on either type of Mac and then using "lipo" on the 
executables and libraries as needed to produce a single arch set of files. Of 
course, that assumes that any third-party libraries needed for the build of 
Python have to also have been built with both archs.

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Need M1 Mac to Test

[Ned Deily]

On Jan 12, 2022, at 15:35, Brian Herman  wrote:
> Do you guys need an M1 mac to test out the latest python?
> I have an extra macbook air m1 I would be willing to give people access to it 
> so they can test the latest python and compile things or I could do it 
> manually.
> My brother said you guys didn't have one yet.

Thank you for the generous offer.  We do already have access to various M1 Macs 
for Python testing including this one already in our buildbot fleet:

https://buildbot.python.org/all/#/workers/44

Perhaps some other Python-related project could use access. 

  --
Ned Deily
n...@python.org -- []___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Apple Silicon, anyone?

[Ned Deily]

On Jul 13, 2020, at 16:08, Jack Jansen  wrote:
> Is anyone planning to track the Apple Silicon stuff and/or get a developer 
> system, and see what needs to be done for Python?

Yes, work is well under way and being tracked in 
https://bugs.python.org/issue41100 and others.

Ronald and I have been working on it along with patches provided by an Apple 
developer (a welcome surprise).  Ronald already has a developer system and has 
also been working on PyObjC support for Big Sur and Apple Silicon.  I hope to 
have a developer system soon.  Note that there are changes in Python that are 
needed for Big Sur even on current Intel platforms.

I expect to publish here and elsewhere in the very near future a plan for how 
we will roll out Big Sur and Apple Silicon support in upcoming Python releases.

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python 3.8 (latest release)problem

[Ned Deily]

On May 30, 2020, at 04:04, Ronald Oussoren via Pythonmac-SIG 
 wrote:
>> On 29 May 2020, at 12:44, Don Bowers  wrote:
>> 
>> iMac (2009)  OS X El Capitan v  10.11.6
>> 
>> Sirs, A few days ago I downloaded and installed the latest release of python 
>> 3.8.3.
>> 
>> All seemed normal at first until I tried to Cut & Paste parts of a script I 
>> was working on in the IDLE
>> environment. The following are screen shots that are generally self 
>> explanatory;
>> 
>> As can be seen, the cut and copy are greyed out and inoperative and I don’t 
>> remember the "set" and "clear" Breakpoints, at the bottom.  It is as if 
>> nothing had been selected.
>> Such a situation makes the editor practically unusable so I quit out of the 
>> IDLE and Python.
> I get the same behaviour on macOS 10.15.5, both with 3.8.3 and the 3.9 beta. 
> 3.7.4 works correctly.   This happens both in the interactive shell and in 
> edit windows.  I’d guess this is a problem with the bundled copy of Tk.
> 
> Could you file a bug on bugs.python.org?

It looks like this problem was caused by a change a couple of months ago for 
Issue39885:

https://bugs.python.org/issue39885

which had the side effect of disabling the cut and copy context menu items.

A fix for that regression was just merged yesterday so the problem should be 
resolved in the next set of releases,
3.8.4 and 3.7.8, which should both be available by mid-July.

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Upgrade to pip 9.0.3 (due to TLS deprecation)

[Ned Deily]

On Apr 6, 2018, at 14:02, Sumana Harihareswara <s...@changeset.nyc> wrote:
> I am not a Mac user and am fairly new to the Python packaging/distribution 
> world, so this may be naive and unrealistic verging on ridiculous, but: is 
> there anything we could ask Apple to do to help with this situation?

For the most part, the current problematic software is not shipped by Apple, 
other than the deprecated OpenSSL libraries, so I don't think there is 
realistically anything they could do to help.

Here is my understanding of the situation regarding Pythons provided by 
python.org installers:

https://github.com/pypa/warehouse/issues/3293#issuecomment-378468534

--
  Ned Deily
  n...@python.org -- []

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Ned Deily]

On 2016-09-13 19:33, Glyph Lefkowitz wrote:
>> On Sep 13, 2016, at 3:35 PM, Andrew Jaffe > > wrote:
>>
>> Aha!
>>
>>  $ ls -lt /Library/Python/2.7/site-packages/
>>  total 0
>>  -rwxr-xr-x  1 root  wheel  157 31 Jul 02:36 Extras.pth*
>>  -rw-r--r--  1 root  wheel  119 31 Jul 02:36 README
>>  $ more /Library/Python/2.7/site-packages/Extras.pth 
>>  /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
>>  
>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC
>>
>> Now I wonder how those got there?!
>>
> 
> Hah!  Thanks for sharing.  Very satisfying to actually make a *correct*
> prediction about setuptools' behavior :)

This seems to be Apple's doing.  AFAICT, 10.12 is shipping with this
Extras.pth file in /Library/Python/2.7; it's something new.  And,
unfortunately, due to https://bugs.python.org/issue4865, the
site-packages directory for the system Python 2.7 is included in
sys.path along with the non-system framework Python site-packages.



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Installing python 2.7.9rc1 caused my frozen apps problems

[Ned Deily]

In article 
cacgdh2hh5cvykbbca+xf3+vkg_hvzbg8mqe7qaiti3ukxwv...@mail.gmail.com,
 Paul Wiseman poal...@gmail.com wrote:

 On 1 December 2014 at 23:57, Ned Deily n...@acm.org wrote:
 
  [duplicate reply as the first seems to have disappeared]
 
  In article
  cacgdh2hoqfsdrfdpblnheeppowquoqskf_bgdovga7+z05e...@mail.gmail.com,
   Paul Wiseman poal...@gmail.com wrote:
   I don't think it's either of those. I think that hashlib.py must have
   changed in 2.7.9 from 2.7.8 (no longer has
  _hashlib.openssl_md_meth_names) so
   the built app (running 2.7.8) expected that attribute to be there, but
   somehow py2app or my usage of it is causing it to look in the system
   libraries over the frozen libraries. Installing 2.7.8 again hides the
  issue
   because whichever hashlib it uses would have the same behaviour because
   they'll be identical (both from v2.7.8)
In any case, a fresh install seems to have solved the problem.
On Dec 1, 2014, at 7:29 AM, Paul Wiseman poal...@gmail.com wrote:
I have a frozen app installed (built on a different machine using
  python
2.7.8 32/ppc)
   
I Installed python 2.7.9rc1 (32/pcc python.org installer) and I
  started
seeing errors from the built app on startup
   
the error occurred from import hashlib
   
  File
   
  /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py
,
line 138, in module
_hashlib.openssl_md_meth_names)
AttributeError: 'module' object has no attribute
  'openssl_md_meth_names'
   
Installing 2.7.8 again on this machine, and the frozen app started
  working
again with no other changes.
   
Is this a problem with my setup or an issue with the freezing process?
 
  The whole point of using py2app in normal, non-alias mode is to provide
  a self-contained, standalone app not dependent on any external
  Python-provided infrastructure, e.g. py files or extension modules or
  shared libs so something is wrong here.  The 'openssl_md_meth_names' was
  added to _hashlib.so for 2.7.9 (along with a lot of other changes to
  support the backport of upgraded ssl functionality from Python 3) so
  what appears to be happening here is that something in your app is
  incorrectly importing hashlib.py from the 2.7.9 installation in
  /Library/Frameworks along with (correctly) importing _hashlib.so from
  your py2app-produced app bundle.
 
 
 Yea I think you're right- I'm pretty sure that's what it must be
 
 
  I'm no expert on py2app but I did
  verify that a very simple app that used hashlib and was built with a
  current py2app and 2.7.8 did, in fact, work correctly when run in the
  presence of 2.7.9rc1.  So the question is what is going on with your
  app.  Questions that come to mind: (1) What is the full traceback (e.g.
  which file causes hashlib to be imported)?  (2) What is the value of
  sys.path at that point?  (3) What third-party modules are installed in
  the app and were any installed after using py2app?
 
 
 This is the full traceback:
 
 Traceback (most recent call last):
   File /Applications/Utility.app/Contents/Resources/__boot__.py, line
 316, in module
 _run()
   File /Applications/Utility.app/Contents/Resources/__boot__.py, line
 311, in _run
 exec(compile(source, path, 'exec'), globals(), globals())
   File /Applications/Utility.app/Contents/Resources/context_main.py, line
 3, in module
 from PythonApp.context.context import main
   File PythonApp/context/context.pyc, line 3, in module  # from
 PythonApp.redirectstd import redirect
   File PythonApp/redirectstd.pyc, line 5, in module  # from PythonApp
 import settings
   File PythonApp/settings.pyc, line 7, in module  # import hashlib
   File
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py,
 line 138, in module
 _hashlib.openssl_md_meth_names)
 AttributeError: 'module' object has no attribute 'openssl_md_meth_names'
 2014-12-01 23:44:57.204 Utility[72506:4648486] Utility Error
 
 I printed out sys.path right before the import hashlib,
 ['/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-
 scriptpackages',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
 '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old',
 '/Applications/Utility.app/Contents/Resources/lib/python2.7/lib-dynload',
 '/Applications/Utility.app/Contents/Resources/lib/python2.7/site-packages.zip'
 ,
 '/Applications/Utility.app/Contents/Resources/lib/python2.7/site-packages']
 
 There's no modifications in the code to sys.path or the pythonpath (I do
 have modifications to PYTHONPATH in my .bash_profile- but those aren't
 showing up in the sys.path

Re: [Pythonmac-SIG] Python 3.4.2 as default version

[Ned Deily]

In article d0b40d9f-a58d-42f1-9674-3b380be3d...@pobox.com,
 Jonathan Lundell jlund...@pobox.com wrote:

  On 26 Nov 2014, at 2:00 PM, Chris Barker chris.bar...@noaa.gov wrote:
  
  On Wed, Nov 26, 2014 at 12:13 PM, Scott Clausen scottclau...@mac.com 
  mailto:scottclau...@mac.com wrote:
  I've been searching the sites to find out how to set the latest version of 
  Python, 3.4.2, as the default version. So far I've not been able to do so.
  
  you put it first on your PATH in .bash_profile
  
  If you installed from the dmg on python.org http://python.org/, it should 
  have done that for you.
  
 
 Though you might want to consider that there are other Python clients around 
 that might not like Python 3 all that well. I've seen a suggestion floating 
 around (Stack Overflow IIRC) that one might create a 'python3' alias, and 
 hash-bang to that where needed. Or whatever.

Python 3.4 normally comes with a python3 alias.  If you use the 
python.org Python 3.4 installers, the default names installed for 
invoking it are: python3 and python3.4 and possible others, like 
python3-32.  It does not include python which is, by default, 
reserved for Python 2.x installations.  One exception is within active 
virtual environments such as provided by virtualenv or Python 3's native 
pyvenv.  If you install a Python 2.7 from python.org, it will be 
accessible by python2.7, python2, and python.  That allows both 
Python 3 and 2 to co-exist.  If you want to override that, you can 
create or modify symlinks in the framework bin directories (in 
/Library/Frameworks) and/or in /usr/local/bin.  Whatever you do, don't 
try to modify or uninstall the Apple supplied system Pythons in /usr/bin 
and /System/Library/Frameworks..

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Package for building DMG installers from pip requirements

[Ned Deily]

In article 
cah6pt5rq0xwy86rt5trzzzirgvdvh25c8_avk4mqvk7xvn1...@mail.gmail.com,
 Matthew Brett matthew.br...@gmail.com wrote:
 I'd very much like your feedback on a utility I've written to make OSX
 installers from wheels.
 
 For my own course, and for matplotlib, I wanted to make an double click OSX
 installer which would install a series of requirements into Python.org Python.

Thanks for looking at this.  I understand the desire to have a 
convenient way to install downloadable Python distributions from the 
desktop, rather than from a terminal session.  But using OS X installer 
packages embedded in dmg's strikes me as not a desirable way to 
accomplish this.  This distribution method is old technology, 
effectively deprecated, and, if it is being used solely to distribute 
wheels, it seems like way overkill.  The primary use case for installer 
packages is when you need to install files in various disparate parts of 
the file system, particularly in system areas that require admin privs 
to do so.   Wheels are themselves a packaging format, managed nicely by 
pip.  Bundling that into a another packaging format, one that doesn't 
even provide an uninstall capability unlike pip, seems wasteful and even 
confusing.  And then embedding *that* in a dmg just makes it more 
complicated, what with mounting images and dismounting and deleting the 
dmg.  If the installer package is a 10.5+ flat package, there's no need 
to embed it in an dmg; that was only necessary for the original, bundle 
format installer packages, which are a collection of directory trees 
with files, rather than a compressed container file.  (Curiously enough, 
I'm working right now on finally transitioning the python.org installers 
away from bundle packages with dmgs to flat packages.)

Another issue with installer packages is that they need to be signed by 
someone with a Mac Developer account from Apple to avoid users having to 
figure out to override Gatekeeper security settings (control-click - 
Open (Installer), rather than double click), a less than ideal user 
experience.

Ideally, IMO, I would like to see us come up with a Python.app that acts 
as a double-clickable GUI front end to Python for OS X.  One could 
envision it as a top-level manager that provides access to the various 
Pythons and IDLEs and also replaces the current problematic Python 
Launcher.app.  It could handle wheels by registering the .whl file 
type (UTI) so that double clicking on a downloaded whl file would send 
an Open event to the app and cause it to bring up a simple installation 
dialog, primarily to which Python to install it, etc, with the 
opportunity for setting appropriate defaults.  The Python.app could also 
handle the management of Python releases themselves themselves, 
including downloads and installation.  (Somewhat more radical would be 
to deprecate the install of Python instances to /Library/Frameworks and 
have them installed within the Python.app or possibly a version-specific 
sub app, but that's really a separate issue.)

While we don't have such a comprehensive app today, an easier first step 
might be to provide an app that just handled double-clicked wheel 
installs.  Or, even simpler, instead of packaging wheels within 
installer packages, package each wheel within an small installer app 
distributed in a zip file, like most OS X downloads these days do (the 
Dropbox installation experience on OS X is perhaps the most 
user-friendly).  In either case, the apps would need to be signed.  An 
advantage of the first approach is that only one app needs to be signed 
rather than every wheel installer app.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] What does it take to run a GUI app?

[Ned Deily]

In article 
calgmxejczecmap_enqhom-9rma9ubx-z6uytruum3arbdgw...@mail.gmail.com,
 Chris Barker chris.bar...@noaa.gov wrote:
 Over on the list for the Anaconda distribution, we've run into a limitation
 in our understanding of the whole app bundle, etc business.
 
 The problem is thus:
 
 Anaconda is currently built with the old python / pythonw dichotomy.

On vanilla OS X python builds, there is no difference between python and 
pythonw; that's been the case going back many years.  pythonw* files 
are/were just symlinks to the correspoing python* files.  In fact, as of 
3.4, we no longer make the pythonw* symlinks.

 python is a standard unix-style executable -- great for command line apps,
 web servers, what have you. But you get the dreaded:
 
 
 This program needs access to the screen.
 Please run with a Framework build of python, and only when you are
 logged in on the main display of your Mac.
 
 
 when you try to run a GUI app (this error message from wxPython)
 
 pythonw, on the other hand, is a shell script that re-directs to a python
 that is inside a hand-built application bundle:
 
 #!/bin/bash
 export
 PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python
 /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py
 thon
 $@

This is something supplied by Anaconda?

 This all sort-of works. But it's a pain, because you may not know when you
 start up an app, whether it needs to access the Window manger (like
 iPython, for instance). And now I need to put pythonw in my #! lines,
 which may fail on other *nix systems, and...
 
 One thought is to simply have python be the same shell script as
 pythonw but there is concern that having it be a re-directing shell
 script may cause problems for some use cases.
 
 I know that this has been solved for years in the python.org installer. So
 how is that done?

A framework build, like used in the python.org installer, creates a 
Python.app app bundle within the framework:

/Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app

and the real Python executable is located there, in 
./Contents/MacOS/Python like a standard OS X app.  The tricky part is 
that a bootstrap executable, built from the somewhat confusingly named 
pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c), 
is what is actually installed into the framework bin directory and 
symlinked to from /usr/local/bin/ or wherever.  The bootstrap 
executable's job is to essentially transparently launch Python.app from 
the command line.  That is, when you type:

/usr/local/bin/pythonx.x 
or
/Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y

you are first executing the bootstrap executable and it then spawns or 
execs the real interpreter executable under Python.app so that Python 
runs as a app that can be a gui process.

Now, these days, most of the time you probably don't need to be a gui 
process, especially since we no longer support the obsolete deprecated 
Mac Carbon-based API wrapper functions in the standard library.  And if 
you are building you own gui app, presumably you can use py2app to 
produce your app as its own app bundle.

I'm not familiar with wxPython at all but, if it doesn't already, it 
might be able to take the approach Tcl/Tk does on OS X.  Tk seems to do 
some tricks to make itself a gui process and it also has an embedded 
Wish.app at least when Tk is built as a framework.  But I haven't looked 
closely at it.  The relevant code in the the Tk file 
macosx/tkMacOSXInit.c.

 Anaconda doesn't seem to want to make their python a proper framework build
 -- don't know why not -- would there be any downside? But is it possible to
 build the python executable so it can access the GUI system without
 structuring their whole python install?

One issue might be that the current framework builds are meant to be 
installed at a fixed path, by default /Library/Frameworks.  You can 
change that at build time but we don't support changing it at install or 
run time.

Without knowing more, I'd look to solving the issue in wx rather than 
Python since it might affect other users as well.  The Python framework 
GUI stuff is quite old and hasn't really been closely examined in a long 
time.  There *might* be better ways to do it today.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python interactive segfaults on OS X 10.9 Mavericks

[Ned Deily]

In article nad-13c89c.17244325102...@news.gmane.org,
 Ned Deily n...@acm.org wrote:
 SInce OS X 10.9 Mavericks is now out, people are running into a severe 
 problem 
 when using some Python interpreters interactively.  The symptom is that the 
 interpreter in interactive mode crashes after typing two lines:
[...]
 The fix for the problem has been released in the current 3.4.0a4 installers.  
 It will be available in the installers for Python 3.3.3 and 2.7.6, which are 
 expected to be released in the near future.  Release candidate installers for 
 both should be available by Monday.
 
 http://bugs.python.org/issue18458
 
 Otherwise, for the most part, the transition to OS X 10.9 appears to be 
 relatively problem-free so far.  Please open issues on the Python bug tracker 
 for any new problems you encounter (after doing a quick search to see if it 
 has already been reported!).

Update: Release candidate installers for 3.3.3 and 2.7.6 are now available:

http://www.python.org/download/releases/3.3.3/
http://www.python.org/download/releases/2.7.6/

In addition, a problem in the Tk 8.5 gui library that may affect users of IDLE 
or other tkinter-based applications running on OS X 10.9 has been fixed 
upstream.  rc1_rev1 installers including the fixed Tk library should be 
available shortly.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building extension modules with Xcode 5

[Ned Deily]

On Oct 28, 2013, at 11:46 , Andrew Barnert abarn...@yahoo.com wrote:

 Sorry, I've been trying to reproduce this, and I haven't identified exactly 
 what the problem is, except that you have to upgrade Xcode from 4.x to 5.0.1 
 after upgrading to 10.9 and without upgrading/reinstalling Python. If I do 
 that, _sometimes_ it doesn't work, with failures looking for gcc-4.2. If I do 
 any other sequence, it always succeeds. I'll keep trying to figure out the 
 repro case.


Thanks, Andrew, for your efforts!  I *really* want to get to the bottom of this 
issue.

I assume you know this but, for the benefit of others new to Xcode 5 and 
Mavericks: Apple has changed some things about the Command Line Tools 
component.  The new way to install the CLT in 10.9 is:
 
   xcode-select --install

TL;DR Just run xcode-select --install.

For some time now (long before Xcode 5), OS X has not shipped with a full set 
of the usual header files, development libraries, and build tools installed, 
e.g. not in /usr/include, /System/Library/Frameworks/.., /usr/bin etc.  They 
are provided in SDKs, one for each OS X release.  If you are using Xcode.app to 
build a project, Xcode takes care of supplying the correct locations of header 
files in SDKs and various build tools.  One advantage of not installing files 
and depending on a fixed path to them is that it simplifies building projects 
for different target platforms: different versions of OS X or, more 
importantly, iOS vs OS X.  Because of that, Apple has seen fit to change the 
locations of things between Xcode releases.  However, many open source 
projects, like Python, expect things to be in their traditional Unix file 
system locations, like /usr/bin/cc or /usr/include/stdio.h.  To accommodate 
such usage, Xcode has also long provided an option to install these files from 
an S
 DK into their tradition location under the system root, /.  This component has 
had various names within Xcode and in the past was selected by an installer 
option then more recently via an Xcode.app - Preferences option.  Also, in 
Xcode 4, bowing to popular demand for a smaller download, Apple made available 
a standalone version of the Command Line Tools that could be downloaded and 
installed without the need for downloading all of Xcode.  Python, like most 
similar open source projects, requires the Command Line Tools to be installed, 
either via Xcode or via the standalone installer.  More accurately, Python 
requires the CLT for two purposes: 1. building C or C++ extension modules with 
Distutils; 2. building Python itself.  If you are using a binary-installed 
Python and don't need to install any third-party extension modules from source, 
you don't actually need the CLT.

For Mavericks, a big initial source of confusion has been how the CLT get 
installed.  10.9 comes with a set of stub files for the CLT build tools, like 
/usr/bin/cc, /usr/bin/gcc, /usr/bin/clang, /usr/bin/make.  The first time you 
try to run one of these tools, a pop-up window appears and asks if you want to 
install the Command Line Tools or install all of Xcode.  If you pick the CLT 
option, an installer package will be automatically downloaded and installed via 
the system installer and, in the future, should be updated via the standard 
Software Update mechanism like other parts of OS X.  When it works, it's very 
slick.  If for some reason, it doesn't work, you may be stumped as to what to 
do.  In the Xcode 5 app, there no longer appears to be a Preferences option to 
install the CLT component.  This has led to a lot of confusion when people look 
for things in /usr/include and find nothing there:  Apple has broken 
everything.  No /usr/include.  (This was exacerbated by a misstep by A
 pple during the Mavericks development cycle that was changed before the 
release.)  The solution to this problem and many other problems is to force the 
install of the CLT and the new way to do it in 10.9 Mavericks is: xcode-select 
--install.

--
  Ned Deily
  n...@acm.org -- []


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python interactive segfaults on OS X 10.9 Mavericks

[Ned Deily]

In article 
cabaqffhvujwai32-rouynfzrncrfmqfs6jhj_bcrabxxkcc...@mail.gmail.com,
 Michael O'Donnell mi...@wagsoft.com wrote:
 Ooops, I spoke too soon.
 
 To repeat, 3.3.3 rc1 works fine with Maverick.
 
 However, after installing python 2.7.6rc1, Idle crashes
 on launch (right click on a .py file, and select Open with...
 and then select Idle (2.7.6rc1).
 
 The idle window pops up for less than a second then disappears.
 No error window appears.
 
 Opening console, I see a line:
 
 28/10/2013 10:53:22.382 com.apple.launchd.peruser.501[137]:
 (org.python.IDLE.32416[1792]) Exited with code: 1

Oh, nasty!  The good news is: it's not a Mavericks or even an OS X specific 
bug in IDLE.  Looks like any attempt at opening a file in IDLE 2.7.6rc1 will 
cause IDLE to crash or hang.  That's rather embarrassing!  I've opened a 
release blocker issue for the problem here:

http://bugs.python.org/issue19426

Thanks very much, Michael, for noticing it!  If you find any other problems, 
please open issues for them on the Python bug tracker if there isn't already 
an issue there.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building extension modules with Xcode 5

[Ned Deily]

In article nad-81273c.19295024102...@news.gmane.org,
 Ned Deily n...@acm.org wrote:
 I'm really confused here.   Using the current 2.7.5 64-bit installer (from 
 May) on 10.8.5 with Xcode 5.0.1 works just fine for me.  Perhaps you are 
 seeing problems because you are trying to override Distutils defaults?  If 
 you 
 don't set any of CC or LDSHARED or other DIstutils environment variables, 
 Distutils should do the right thing.  If you do set the env variables, 
 Distutils assumes you know what you are doing and honors the values you 
 supply.

Ah, while my comment above is accurate concerning the current 64-bit 
installers, it did slip my mind that there *is* an Xcode 5-related problem 
when using the legacy *32-bit-only* installers for Python 3.3.2 and 2.7.5 on 
10.8 or 10.9 with Xcode 5.  Basically, the problem is that the test that 
Distutils currently uses during extension module builds to detect whether the 
compiler supports PPC architectures fails due to behavior changes in Xcode 5.

The problem was already fixed in the 3.4.0a4 installer and will be fixed in 
3.3.3 and 2.7.6, for which release candidate installers should be available by 
Monday.  To highlight the issue, I have created Issue19400 which describes the 
problem in more detail and documents a workaround, i.e. using the ARCHFLAGS 
environment variable to override universal architectures for ext module builds.

Perhaps this is the problem people have been seeing with Xcode 5?  My 
apologies for not thinking of it earlier.  Otherwise, I am not aware of any 
other problems with using Xcode 5 for extension module builds.  Please open 
issues on the Python bug tracker if you find any problems!

http://bugs.python.org/issue19400

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Python interactive segfaults on OS X 10.9 Mavericks

[Ned Deily]

SInce OS X 10.9 Mavericks is now out, people are running into a severe problem 
when using some Python interpreters interactively.  The symptom is that the 
interpreter in interactive mode crashes after typing two lines:

$ python3.3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
 Hello  # first line OK
'Hello'
 World  # second line causes crash
Segmentation fault: 11

It does not matter what is entered on the two lines; the interpreter crashes 
after the second line.  The problem is caused by an upstream change in the OS 
X 10.9 editline library, libedit.  Most recent versions of the python.org 
installers dynamically link to the system-provided libedit and are susceptible 
to the problem.  These include Pythons from the following current installers:

3.3.2 64-bit/32-bit 10.6+
3.3.2 32-bit-only 10.5+
2.7.5 64-bit/32-bit 10.6+

Older releases of similar installers are also susceptible.  2.7.x Pythons from 
the 32-bit-only installers are not susceptible because they do not use 
libedit.  Pythons using GNU readline, including those with the PyPI readline 
distribution installed should not have problems.  The problem is described in 
Issue18458.  It describes a workaround: disabling the readline extension by 
renaming or deleting it.  It also provides a script that can be downloaded to 
automate this patching.

The fix for the problem has been released in the current 3.4.0a4 installers.  
It will be available in the installers for Python 3.3.3 and 2.7.6, which are 
expected to be released in the near future.  Release candidate installers for 
both should be available by Monday.

http://bugs.python.org/issue18458

Otherwise, for the most part, the transition to OS X 10.9 appears to be 
relatively problem-free so far.  Please open issues on the Python bug tracker 
for any new problems you encounter (after doing a quick search to see if it 
has already been reported!).

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building extension modules with Xcode 5

[Ned Deily]

In article 1382658638.14083.yahoomail...@web184703.mail.ne1.yahoo.com,
 Andrew Barnert abarn...@yahoo.com wrote:

 If you use a binary installer of Python 2.7.5, 3.3.2, or 3.4.0a4 from 
 python.org on either 10.8 or 10.9, and you have Xcode 5, you can't build any 
 C extension modules, because you don't have a compiler named gcc-4.2.

This should not be the case.  Can you show an example of how this is failing?  
As long as you do not manually override by setting environment variables like 
CC and LDSHARED, Distutils on currently released python.org Pythons (2.7.5, 
3.3.2, and 3.4.0a4) should continue to do the right thing and substitute clang 
if the compile it was built with is not present.  In fact, Distutils 
explicitly blacklisted the llvm-gcc shipped with Xcode 4.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building extension modules with Xcode 5

[Ned Deily]

In article 1382665677.4566.yahoomail...@web184704.mail.ne1.yahoo.com,
 Andrew Barnert abarn...@yahoo.com wrote:
 Also Python having a single binary for 10.6+. I understand that decision—the 
 only alternatives are to tell 10.6 users they're stuck with 2.7.5/3.3.2 
 forever, or to double the number of builds and double the packagers' work. 
 But Apple consistently and intentionally makes it hard to support more than 3 
 (sometimes even 2) major OS X versions at a time, and they do a good job of 
 that.

I'm really confused here.   Using the current 2.7.5 64-bit installer (from 
May) on 10.8.5 with Xcode 5.0.1 works just fine for me.  Perhaps you are 
seeing problems because you are trying to override Distutils defaults?  If you 
don't set any of CC or LDSHARED or other DIstutils environment variables, 
Distutils should do the right thing.  If you do set the env variables, 
Distutils assumes you know what you are doing and honors the values you supply.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building redistributable binaries with Xcode 4.4+

[Ned Deily]

In article 1382659117.96447.yahoomail...@web184704.mail.ne1.yahoo.com,
 Andrew Barnert abarn...@yahoo.com wrote:
 There's a related issue, using the 10.6 SDK. This one is over a year old, but 
 as far as I know still has no solution.
 
 Xcode 4.4+ have no 10.6 SDK. This doesn't actually stop you from building 
 extensions; they just falls back to building for your machine when it can't 
 find the SDK. But that means you can't build binary distributions of your 
 extensions (or py2app executables, etc.). So, if you want to create useful 
 Python binaries, you have to either keep an old development machine around, 
 or build Python yourself.

I agree this is a shortcoming of the current Distutils processing in the 
currently Python releases.  If you really do need to build with a different 
SDK, it would be nice if Distutils made it easier to do.  As it stands now, 
you need to manually override Distutils settings by using sysconfig to get the 
current configuration variable values for CFLAGS and LDSHARED, possibly 
others, and then edit them to insert the desired value for -isysroot path to 
sdk and set the corresponding environment variables as well as 
MACOSX_DEPLOYMENT_TARGET.  It's not elegant.  But it should work.  I would 
like to add something to make that easier.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] avoiding system's easy-install.pth with custom distribution

[Ned Deily]

In article 
calzqqjbkh5cwrf6hpclc7nurkmbajutr3tyro_wqxjzl9vv...@mail.gmail.com,
 Nat Echols nathaniel.ech...@gmail.com wrote:
 I'm distributing a large cross-platform Python-based application, for which
 we bundle Python 2.7 and a number of dependencies (wxPython, matplotlib,
 etc.).  We've tried to make it as self-contained as possible, to prevent
 either a) polluting the user's environment and potentially breaking other
 programs, or b) breaking our program because other software pollutes the
 environment.  This means wiping out PYTHONPATH at runtime, which has worked
 quite well for us.
 
 What I've now discovered is that at least on OS 10.7.5, if a user installs
 packages for the system python using easy_install (possibly other
 mechanisms as well, but that's what worked for me), these will now end up
 in the search path for our app's python interpreter, and override many of
 the packages we distribute because they appear relatively early in
 sys.path.  The problem appears to be traceable to this file:
 
 /Library/Python/2.7/site-packages/easy-install.pth
 
 which modifies sys.path directly.  Removing or renaming that file leaves
 our custom distribution's path alone.  So, two questions:
 
 1) Why is this happening?  It seems incredibly broken - but I have no idea
 who's fault it is, for all I know we're doing something foolish when we
 compile Python on our build system (10.6, if it matters).
 
 2) Is there any way we can modify our distribution to avoid this?

The behavior is the result of a feature added in 2.7 for Issue4865 which 
appends the site-packages directory for the Apple-supplied system Python 
to sys.path of a Python framework build.  With hindsight, I don't think 
this was a good idea and you are not the first to complain about it 
(see, for instance, Issue15048).  OTOH, as Ronald pointed out in that 
issue, there isn't a complete separation between Python frameworks 
anyway: they all share the user site-packages directory 
(~/Library/Python for a framework build) and configuration files (like 
for Distutils and IDLE).  It is late in the game to make a change like 
this in Python 2.7.x which is nearing the end of its supported life.  
It's not too late, IMO, to change current Python 3 before it becomes an 
issue;  it's not an issue yet because Apple has not yet shipped anything 
newer than Python 2.7.x.  Feel free to chime in on the bug tracker.

The path appends occur in the standard library site module.  You could 
patch it in your own interpreter to not include /Library/Python; you 
might be also be able to do it by supplying a sitecustomize module.  
See site.py for details.

http://bugs.python.org/issue4865
http://bugs.python.org/issue15048
http://hg.python.org/cpython/file/2.7/Lib/site.py#l305

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Python 3.4.0 alpha 2 available

[Ned Deily]

I would like call your attention to the latest alpha release of Python 
3.4.0 and a new batteries-included feature for OS X users.  For 
3.4.0.a2, the python.org 64-bit/32-bit installer now includes its own 
private version of Tcl/Tk 8.5.14 so it is no longer necessary to install 
a third-party version of Tcl/Tk 8.5 to workaround the problematic system 
versions shipped in OS X 10.6+.  Unlike Pythons from previous 
installers, only this private version will be used by tkinter and IDLE. 
It will have no effect on or be affected by any other versions of Tcl/Tk 
installed on your system, such as ActivelTcl 8.5.x or Apple 8.5.x.

Since this is a new feature and somewhat experimental, it may change 
prior to the official release of Python 3.4.0, planned for 2014-02.  
There will be other OS X installer-related changes coming.  Please 
report any problems or issues you encounter to the Python bug tracker.  
Thanks!

http://www.python.org/download/releases/3.4.0/
http://www.python.org/download/mac/tcltk/
http://bugs.python.org

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] OS X IDLE and Tkinter users: new releases of Tcl/Tk Python

[Ned Deily]

As I hope you've read already, new releases of Python are now available:  
3.3.2, 3.2.5, and 2.7.5.  There is also a recent release of Tcl/Tk 8.5: 
8.5.14.  If you use Tkinter apps, like IDLE, from one of the python.org 
64-bit/32-bit OS X installers for 3.3.x, 3.2.x, or 2.7.x for OS X 10.6, 
10.7, or 10.8, it would be great if you could install and try out these 
latest combinations.  Tkinter apps have proven to turn up edge cases in 
the newer Cocoa implementation of Tk 8.5 on OS X;  a number of problems 
have been fixed in recent releases.  Since these kinds of problems are 
difficult to test for automatically, it is important to get real user 
experience and feedback.  Please report any suspected new problems to 
the Python bug tracker.  Thanks for your help!

http://www.python.org/download/
http://www.python.org/download/mac/tcltk/
http://www.activestate.com/activetcl/downloads
http://bugs.python.org

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Environment variable issues running py2app application

[Ned Deily]

In article 
cacgdh2jujjuvuekoxpr2e4utje3zdyad8ox9jcffplhghbx...@mail.gmail.com,
 Paul Wiseman poal...@gmail.com wrote:
 I've never seen this problem before but one user seems to be experiencing
 this issue and I'm at a bit of a loss as to what the cause could be
 
 One part of the app runs this: subprocess.Popen(['/usr/bin/env',
 'system_profiler', 'SPUSBDataType', '-xml'])
 
 I've never seen a problem running this, however in one users logs it's
 returning: env: system_profiler: No such file or directory
 
 So I thought that maybe their PATH variable doesn't include path to the
 binary, I asked them to provide the output of '/usr/bin/env' and 'which
 system_profiler'
 
 'which system profiler' returned '/usr/sbin/system_profiler' and
 '/usr/sbin' was in their PATH variable that returned from /usr/bin/env, so
 I don't really get what's going on.
 
 This also looks like it only happens if the user opens the .app directly,
 but if they open the binary directly in the .app/Contents/MacOS/ folder, it
 works and it can find these external binaries through subprocess.
 
 I'm really not sure what might be causing this? and I've never experienced
 it myself when testing, nor has it ever been reported before which makes me
 inclined to believe it's some external setting / config on the users
 machine which is causing this behaviour?

Normally, a shell (like bash) is not involved in launching an OS X app 
bundle, like those produced by py2app, so the environment variables seen 
in an app's environment are not the same as what is seen from a terminal 
shell session.  Thus, the output of `which` and of the user's shell 
$PATH aren't relevant.   It used to be possible to influence to the 
user's GUI environment by supplying a ~/.MacOSX/environment.plist but I 
believe that is no longer supported on current OS X releases and, in any 
case, it's a bad idea to depend on it.  It is possible to include 
app-specific environment variables in the app's plist.  But, in your 
case, the simplest thing to do is use an absolute path to 
`system_profiler` and avoid use of `/usr/bin/env` within an app bundle.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Query Regarding IDE for python for GUI Apps

[Ned Deily]

In article 5cc02f7c-f5a0-4c3a-830b-3a5d5d81a...@mcgill.ca,
 Henry Olders henry.old...@mcgill.ca wrote:
 TextMate is a mac text editor which has a number of features that I like 
 because they reduce the number of keystrokes, including search and replace 
 within projects.
 http://macromates.com

I'm a big fan of TextMate as well.  TM has had a bit of a checkered past 
but a lot has changed recently.  After great success for several years 
with its first version, development seemed to stall.  The long-promised 
rewrite failed to appear year after year and gained the reputation of 
Duke Nukem Forever vaporware.  But last year, Allan Odgaard took the 
major step of open sourcing TextMate 2 on GitHub and inviting community 
collaboration on it.  (Note, the language-specific plugins for TM 1 have 
always been open sourced.)   TM2 development has since become very 
active and, although it is still in alpha status, I've found it to be 
very stable and bringing many improvements to what is in TM1.  If you 
find it useful, I would encourage you to contribute to its development 
by purchasing an official license for TM1 but, because TM2 is open 
source, you can use it for free.  Besides the development alpha builds, 
TM2 is also available through MacPorts.

https://github.com/textmate/textmate/downloads

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] bdist_mpkg question: python 3 support?

[Ned Deily]

In article 
CALGmxELrdvrMnQ0HnQnogu3d-6g3CPsXUsbkp=en1uufxxf...@mail.gmail.com,
 Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote:
  The real problem with binary eggs is that pip doesn't install them, and pip 
  seems to be the
  new hotness w.r.t. package management at the moment.
 
 Indeed it does -- I hadn't realized it didn't install binary eggs -- I
 guess it's been a while since I've tried that!
 
  There is some discussion about a new format (see 
  http://www.python.org/dev/peps/pep-0427/, but I'm not sure why that would 
  be better than eggs (other than that it isn't a setuptools egg).
 
 It looks like it has some advantages -- but it's not there now, and
 who knows if it ever will be...
 
  The packaging landscape for Python still sucks and that might not change 
  anytime soon.
 
 :-(
 
  But setup tools used to get all confused by Universal binaries--has
  that been fixed? If not, it still may be easier to fix that than do a
  bdist_mpkg update.
 
  Setuptools works just fine with universal binaries, and always has.
 
 it build binaries fine, but easy_install got confused when you tried
 to install them.
 
  It does treat 'universal' like any other architecture though, which means 
  it doesn't understand
  that a binary egg with x86_64 only will work just fine when you are on a 
  x86_64 machine
  with a python framework that supports i386 and x86_64. Whether or not that 
  is a problem
  depends on your usecase.
 
 It would be nice to suport that use-case, though it's ripe for
 confusion for casual users.
 
 But at least a couple years ago, if you build a binary egg with
 setuptools with a universal Python, you'd get an egg that setuptools
 would get confused trying to install -- I can't remember the details,
 but often when a user tried to install it, easy+install would end up
 downloading the source and trying to build it. IIRC, often it had, in
 fact, successfully installed the binary, so you could kill the process
 and have it work -- but that wasn't the least bit clear to the user.
 
 I also have a vague recollection that you could fix that problem
 simply be re-naming teh binary but my memory is hazy there.

Yes, that's what Ronald is talking about with regard to architectures.  
The platform architecture is encoded into the file name of the egg.  For 
OS X universal builds, the platform names are things like fat (meaning 
the build includes i386 and ppc) or intel (i386 32-bit and 
x86_65 64-bit).  IIRC, the problem is that setuptools/Distribute just 
does a simple equality compare of that platform name from the egg to 
that of the running Python at install time when what is needed is a set 
comparison, i.e. something like: is there a non-null intersection 
between the set of archs supported by the binaries in the egg with the 
set of archs supported by the Python interpreter being used for 
installation.  (Today you can force a true comparison by changing the 
name of the binary egg file so that the platform strings match.)

 It seems binary egg installation should be pretty easy, and it doesn't
 look like the pip folks are opposed to the idea, so maybe we could add
 that to pip, if distribute builds them properly anyway.

It's not trivially easy or it probably would have been done before.  
IIRC, Setuptools/Distribute has to do some behind the scenes 
platform-specific tricks to ensure that dynamic loads of the extension 
modules work, certainly for zipped binary eggs.  To a large extent, it's 
the tricks that setuptools uses (this and the manipulation of sys.path)
to support various use cases that has given setuptools/Distribute a bad 
rep.  pip makes some important simplifying assumptions; not supporting 
binary eggs is one of them.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Getting control over the Apple menu

[Ned Deily]

In article 509308e1-ed1e-4ccb-8efe-f672e2b97...@mac.com, w...@mac.com 
wrote:
 On Nov 1, 2012, at 10:43 AM, Kevin Walzer k...@codebykevin.com wrote: 
  On 11/1/12 9:37 AM, w...@mac.com wrote:
  When running the script directly in the interpreter, that is, when I 
  invoke is as $ ./CM_GUI_2.py in a terminal window (or as $ python 
  CM_GUI_2.py) the first menu to the right of the Apple icon (the one I'd 
  call the Application menu) remains named Python - although the menu 
  under it now includes the items I've created.
  
  That's expected behavior. The application name in the app menu corresponds 
  to the actual executable that is running the app. When you run the app in 
  Terminal, the executable is Python. When it's wrapped with py2app, the 
  executable is the actual app name (actually, the stub executable created by 
  py2app, but which is renamed to match your app). You shouldn't expect to 
  see anything but what you are seeing.
 Good - that's pretty much what I deduced after thinking about your answer 
 last night.  Then Ned's post made me scratch my head.

Sorry for the confusion.  I interpreted your previous post to mean that 
using the 'apple' menu didn't behave the same in both cases, i.e. extra 
menu cascade.  To expand on the app name a bit, the application name 
displayed in the menu comes from the Info.plist of the app bundle under 
which your Python script is running.  With a standard framework build of 
Python, there is a Python.app bundle included in the Python framework so 
that OS X treats the execution as from a full-blown app and certain gui 
features work.  That Python.app bundle has the name Python in the 
plist.  py2app, of course, creates a custom app bundle including an 
Info.plist with the app name you specify.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Getting control over the Apple menu

[Ned Deily]

In article d80a7264-c2e3-40b1-be19-d349be889...@mac.com, w...@mac.com 
wrote:
 On Oct 31, 2012, at 9:11 PM, Kevin Walzer k...@codebykevin.com wrote: 
  On 10/31/12 5:48 PM, w...@mac.com wrote:
  applemenu = Menu(menubar, tearoff = FALSE)
  
  Add the apple name to the menu object, cf:
  
  applemenu = Menu(menubar, tearoff = FALSE, name='apple')
  
  That works for me.
 Thanks, that DOES work for the version packaged up with py2app.  I guess 
 there really just isn't anything to do for it when it is running directly in 
 the interpreter.

It works for me.  Py2app should have nothing to do with tkinter menus 
other than possibly the application name.  The code should work equally 
well in the interpreter or with a py2app-bundled app.  Are you sure you 
are invoking the right interpreter if you are depending on the shebang 
line?

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building a 32 bit framework build in a 64 bit system

[Ned Deily]

In article 
calgmxe+taozml2ftp8b6ao9grlyfgkaozgc4odv8ceexdd8...@mail.gmail.com,
 Chris Barker chris.bar...@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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python 3.3 on OSX 10.8.2

[Ned Deily]

In article 50760282.1040...@codebykevin.com,
 Kevin Walzer k...@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=detailatid=112997aid=3575664group
_id=12997

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python 3.3 on OSX 10.8.2

[Ned Deily]

In article 50737897.9030...@codebykevin.com,
 Kevin Walzer k...@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=detailatid=112997aid=3575664grou
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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python 3.3 on OSX 10.8.2

[Ned Deily]

In article 5072aabc.8050...@codebykevin.com,
 Kevin Walzer k...@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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] IDLE Crashes when Prefs are accessed on Python 3.3 on OSX 10.8.2

[Ned Deily]

In article 50734448.30...@codebykevin.com,
 Kevin Walzer k...@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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app error

[Ned Deily]

In article 
CALGmxELzopN9OMAtpYM3eQ4LEBM1j6oBNZPAd=tytaq2z5r...@mail.gmail.com,
 Chris Barker chris.bar...@noaa.gov wrote:
[...]
 Anyway, on the pyton,org site, there are:
 
 Python 3.2.3 Mac OS X 64-bit/32-bit x86-64/i386 Installer (for Mac OS
 X 10.6 and 10.7)
 
 and
 
 Python 3.2.3 Mac OS X 32-bit i386/PPC Installer (for Mac OS X 10.3 through 
 10.6)
 
 These are what they seem to be -- though I think you got tripped up by
 for Mac OS X 10.3 through 10.6  -- actually, that should be 10.3 +
  -- 10.7 didn't exist when that was built.

Actually, 10.3 through 10.6 is intentional.  If you need to build 
extension modules, the current 3.2.3 and 2.7.3 32-bit python.org Pythons 
do not work well with Xcode 4, the default for OS X 10.7 and 10.8 and 
optional for 10.6.  The upcoming Python 3.3 release has much better 
support for Xcode 4 so that it is practical to use the 32-bit-only 
Python to build extension modules on newer releases.  Some of that 
support will be backported for upcoming 2.7.x and 3.2.x releases.

BTW, for Python 3.3, the 32-bit-only installer Python supports 10.5+ 
systems (i386 and ppc).   More details on all of this forthcoming.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyQT on Lion?

[Ned Deily]

In article 010e9186-252a-459c-8be8-9de05fc0e...@mac.com,
 Arana Fireheart aranafirehe...@mac.com wrote:
 Okay, I GIVE UP!!
 
   I have tried just about everything I can think of and they all failed! 
 I 
 have spent over a month on this and can't seem to get all of these pieces to 
 work together.
 
   I have tried all the latest developers releases for QT, sip and PyQt 
 and all 
 I can get to is a wrong architecture message (see below). I have tried 
 virtualenv and no virtualenv. I have tried to force python to use 32-bit 
 (defaults write com.apple.versioner.python Prefer-32-Bit -bool yes), without 
 any change. I think it is an issue with 32/64-bit versions, but I can't 
 figure out which piece is the one using the wrong architecture...
 
   If ANYONE has managed to get PyQt to build and install on Lion, could 
 you 
  please let me know how you did it...
 
 Arana
 
 
 from PyQt4 import QtCore
 ImportError: 
 dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-pa
 ckages/PyQt4/QtCore.so, 2): no suitable image found.  Did find:
   
 /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/
 PyQt4/QtCore.so: mach-o, but wrong architecture

For what it's worth, the defaults trick to run in 32-bit-mode is an 
Apple modification to their system Pythons in 10.6 and 10.7, i.e. 
/usr/bin/python* and /System/Library/Frameworks/Python.framework.   It 
doesn't work with other Pythons, which you apparently have installed 
(/Library/Frameworks/Python.framework).  Which Python are you using?  
You can determine what architectures are involved by using the file 
command:

cd /Library/Frameworks/Python.framework/Versions/2.6
file ./lib/python2.6/site-packages/PyQt4/QtCore.so
file ./bin/python2.6

There must be a common subset of architectures and the interpreter has 
to running in one of those common archs.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyQT on Lion?

[Ned Deily]

In article 7a6b804d-970e-4000-b540-a79a84257...@mac.com,
 Arana Fireheart aranafirehe...@mac.com wrote:
   It appears that I have two issues. First is that I am not using the 
 system 
 python (maybe I shouldn't be), secondly that the version of PyQt in that 
 directory is compiled for 64 bit. At least that is what I believe the 
 following is telling me... ???

 Aranas-BIG-Toy:PyQt Install arana$ cd 
 /Library/Frameworks/Python.framework/Versions/2.6
 Aranas-BIG-Toy:2.6 arana$file 
 ./lib/python2.6/site-packages/PyQt4/QtCore.so
 ./lib/python2.6/site-packages/PyQt4/QtCore.so: Mach-O 64-bit bundle x86_64
 Aranas-BIG-Toy:2.6 arana$file ./bin/python2.6
 ./bin/python2.6: Mach-O universal binary with 2 architectures
 ./bin/python2.6 (for architecture ppc):   Mach-O executable ppc
 ./bin/python2.6 (for architecture i386):  Mach-O executable i386
 
 Aranas-BIG-Toy:2.6 arana$ which python
 /usr/bin/python
 Aranas-BIG-Toy:2.6 arana$ file /usr/bin/python
 /usr/bin/python: Mach-O universal binary with 2 architectures
 /usr/bin/python (for architecture x86_64):Mach-O 64-bit executable x86_64
 /usr/bin/python (for architecture i386):  Mach-O executable i386
 
 Aranas-BIG-Toy:2.6 arana$ echo $PATH
 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Library/Frameworks/
 Python.framework/Versions/Current/bin
 Aranas-BIG-Toy:2.6 arana$ echo $PYTHONPATH

I know nothing about PyQt4 and I don't know which Python you should be 
using but what the above says is that you are using a non-system Python 
2.6 that is 32-bit-only and you've installed to it a version of PyQt4 
whose extension module QtCore is built only for 64-bit.  So, yeah, that 
won't work.

All I can do is to echo Tom's earlier advice to use a package manager 
like MacPorts for a complete solution including Python.  Trying to build 
and install projects on OS X with multiple dependencies on third-party 
libraries is fraught with gotchas as you are seeing.  Let someone else 
do the hard work of integrating all the pieces.  There may be a little 
time at the beginning to get used to the package manager's quirks but it 
will almost certainly pay off in the long run.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building Python 2.7 with ppc64

[Ned Deily]

In article 
1336304827.59161.yahoomail...@web120705.mail.ne1.yahoo.com,
 Chris Calderon calderon.christian...@yahoo.com wrote:
 Hello All! This is my first time using this mailing list yay!
I am having a 
 problem building Python 2.7 for my quad G5 PowerMac, and I was wondering if 
 anyone has any experience doing this? I don't want a 32-bit build, because I 
 have 8 gigs of RAM I want to be able to use. My os is Mac OS x 10.5.8, and I 
 have Xcode 3.1 installed. I tried to build and install like this:


 ./configure --enable-framework --enable-universalsdk=/ 
 --with-universal-archs=64-bit
make
make install

This installed python, 
 supposedly, but didn't build tkinter or sqlite3, and lots of other stuff 
 didn't build all the way. What should I do

Ýto get this to install 
 correctly? are their other libraries I need to install first? Has anyone 
 successfully built python 2.7 for ppc64?

The Python project has no OS X ppc64 buildbots so we make no claims to   
test Mac G5 platforms.  I've never had a G5 to attempt executing a ppc64 
architecture.  I have built 4-way (ppc, ppc64, i386, x86_64) framework 
builds in the past for some versions but not recently.  That said, we 
hope that ppc64 works and try not to break it.

There are a few known gotchas, though.  Tkinter support for ppc64 is not 
available out of the box.  The Tcl/Tk 8.4 supplied by Apple with OS X 
10.5 is a Carbon Aqua version which supports 32-bit (ppc or i386) only.  
This is also true of the more up-to-date ActiveState's ActiveTcl 8.4.  
ActiveState supplies a Cocoa Tcl/Tk 8.5 for 10.5+ but only for i386 and 
x86_64.  If you really need Tkinter, your best bets are probably either 
to build a 64-bit version of the X11-based Tcl/Tk 8.5 and link with that 
when building a 64-bit Python; or, build a 32-bit/64-bit universal 
Python (--with-universal-arch=all 
--enable-universal-sdk=/Developer/SDKs/MacOSX10.5.sdk) and run in 32-bit 
mode when needing Tkinter.  On 10.5 32-bit-mode is preferred by default 
so you would have to force 64-bit mode when launching a 32-/64- bit 
Python by using something like this:

arch -ppc64 python2.7 ...

Or look into modifying the framework Python.app plist to change the 
order of preferred archs.

The problem with the sqlite extension not building is likely the problem 
documented here: http://bugs.python.org/issue14572.  The best workaround 
for that is probably to build a universal version of libsqlite3 and link 
Python with that; the version supplied with 10.5 is quite old.  You 
might be able to tweak the Python installer build script 
(Mac/BuildScript/build-installer.py) to do that for you; currently, it 
only builds its own version of sqlite3 if the deployment target is less 
than 10.5.

Once you have built a Python, I would highly recommend that you run the 
full Python test suite, perhaps:

python2.7 -m test.regrtest -w -uall,-largefile


Good luck!

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python completion in emacs fails on OSX

[Ned Deily]

In article 87ehrn80aj@gmail.com, Leo sdl@gmail.com wrote:

 It seems the python interpreter built by Apple doesn't behave like the
 ones built from upstream.
 
 See this:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10295#19
 
 Any idea what's happened to python from apple?

Off the top of my head, I suspect the most likely cause to be that the 
Apple system pythons are built with the BSD editline library rather than 
with GNU readline.  You could try installing the third-party readline 
package which replaces the Python standard library readline module 
with one linked with GNU readline. 

http://pypi.python.org/pypi/readline

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building numpy/scipy for python3 on MacOS Lion

[Ned Deily]

In article 1332549773.19437.yahoomail...@web29505.mail.ird.yahoo.com,
 Eddy Barratt eddybarra...@yahoo.co.uk wrote:
 Yeah, thanks, your right I typed it in wrong, but it still isn't working, 
 though it did build for longer this time before failing.
 
 This is the error code this time. It talks about something 
 being depreciated in numpy. Thank you so much for your help with this.
 
 Eddy
 
 compiling C sources
 C compiler: clang -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 
 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -isysroot 
 /Developer/SDKs/MacOSX10.6.sdk
 
 compile options: '-DNO_ATLAS_INFO=3 -DUSE_VENDOR_BLAS=1 
 -I/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-package
 s/numpy/core/include 
 -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c'
 extra options: '-msse3'
 clang: scipy/sparse/linalg/dsolve/_superlumodule.c
 In file included from scipy/sparse/linalg/dsolve/_superlumodule.c:18:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/arrayobject.h:15:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/ndarrayobject.h:17:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/ndarraytypes.h:1972:
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: #warning Using 
 deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API 
 [-W#warnings]
 #warning Using deprecated NumPy API, disable it by #defining 
 NPY_NO_DEPRECATED_API
  ^
 scipy/sparse/linalg/dsolve/_superlumodule.c:268:9: error: non-void function 
 'PyInit__superlu' should return a value [-Wreturn-type]
         return;
         ^
 1 warning and 1 error generated.
 In file included from scipy/sparse/linalg/dsolve/_superlumodule.c:18:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/arrayobject.h:15:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/ndarrayobject.h:17:
 In file included from 
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/ndarraytypes.h:1972:
 /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/
 numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: #warning Using 
 deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API 
 [-W#warnings]
 #warning Using deprecated NumPy API, disable it by #defining 
 NPY_NO_DEPRECATED_API
  ^
 scipy/sparse/linalg/dsolve/_superlumodule.c:268:9: error: non-void function 
 'PyInit__superlu' should return a value [-Wreturn-type]
         return;
         ^
 1 warning and 1 error generated.
 error: Command clang -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g 
 -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 
 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DNO_ATLAS_INFO=3 
 -DUSE_VENDOR_BLAS=1 
 -I/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-package
 s/numpy/core/include 
 -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c 
 scipy/sparse/linalg/dsolve/_superlumodule.c -o 
 build/temp.macosx-10.6-intel-3.2/scipy/sparse/linalg/dsolve/_superlumodule.o 
 -msse3 failed with exit status 1

The deprecation warning isn't necessarily a problem but the compile 
error is.  Sorry, I have no experience with scipy so I would only be 
guessing what the problem here is.  Suggest you ask on the Scipy-User 
mailing list (http://www.scipy.org/Mailing_Lists).  Good luck!

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building numpy/scipy for python3 on MacOS Lion

[Ned Deily]

[Please keep the discussion on the list.  Thanks!]

On Mar 23, 2012, at 11:46 , Eddy Barratt wrote:

 Thanks Ned, that's great, now I can get numpy to import so I'm definitely 
 getting somewhere. But scipy still won't build, it 'failed with exit status 
 1'. The error message included the command about LDSHARE in it's final 
 paragraph. I've included the error message at the end of this email, starting 
 from the part where it appears to have run in to issues.
 
 I have Xcode 4.2.1.
 
 Thanks for your help. Eddy
 
 Error Message:
 
 compiling C sources
 C compiler: clang -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch 
 x86_64 -Os -w -pipe -march=core2 -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall 
 -Wstrict-prototypes
 
 compile options: 
 '-I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include
  
 -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include
  
 -I/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/include/python2.7
  -c'
 clang: scipy/cluster/src/vq_module.c
 clang: scipy/cluster/src/vq.c
 clang -bundle -undefined dynamic_lookup  -arch i386 x86_64 
 -isysroot/Developer/SDKs/MacOSX10.6.sdk -g 
 build/temp.macosx-10.5-intel-2.7/scipy/cluster/src/vq_module.o 
 build/temp.macosx-10.5-intel-2.7/scipy/cluster/src/vq.o 
 -Lbuild/temp.macosx-10.5-intel-2.7 -o 
 build/lib.macosx-10.5-intel-2.7/scipy/cluster/_vq.so
 clang: error: no such file or directory: 'x86_64'
 clang: error: no such file or directory: 'x86_64'
 error: Command clang -bundle -undefined dynamic_lookup  -arch i386 x86_64 
 -isysroot/Developer/SDKs/MacOSX10.6.sdk -g 
 build/temp.macosx-10.5-intel-2.7/scipy/cluster/src/vq_module.o 
 build/temp.macosx-10.5-intel-2.7/scipy/cluster/src/vq.o 
 -Lbuild/temp.macosx-10.5-intel-2.7 -o 
 build/lib.macosx-10.5-intel-2.7/scipy/cluster/_vq.so failed with exit status 
 1


It looks like a copy and paste error.  Note the environment variable settings I 
suggested were:

$ export CC=clang
$ export LDSHARED='clang -bundle -undefined dynamic_lookup \
-arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -g'

But in the Distutils output I see:  -arch i386 x86_64

--
  Ned Deily
  n...@acm.org -- []


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyCon..

[Ned Deily]

In article 20120311020302.ga31...@illinois.edu,
 Nicholas Riley njri...@illinois.edu wrote:
 On Sat, Mar 10, 2012 at 04:56:26PM -0800, Ronald Oussoren wrote:
  On 10 Mar, 2012, at 15:05, Chris Barker wrote:
   On Tue, Feb 14, 2012 at 7:23 AM, Ned Deily n...@acm.org wrote:
   I'm planning to sprint through Thursday.   I've added a  Mac OS X 
   Support
   project to the PyCon sprint page.  Feel free to add topics and add
   yourself.  Hope to see you all there!
 I'm at PyCon (with a laptop/external drive that has 10.6, 10.7 and
 10.8 installed, so I can do some testing across OSes) and should be
 able to spend a day or two sprinting on MacPython.

Great!

Thanks, Ronald, for the summary.   The highest-priority items I think 
are to get Python 3.3 ready for release and to have more robust 
solutions (for 3.2 and 2.7, as well at 3.3) for extension module 
building with the multiple Xcode versions for 10.6+.   But there are 
plenty of open issues to work on and, for 3.3, potential new features.   
For anyone who is interested, it would be great if you could attend the 
Intro to Sprints session at 4:30p following the Sunday afternoon 
Lightning Talks to find out more about the logistics.  Otherwise, 
contact me directly.  I believe the sprint space will be available in 
the adjacent Hyatt from Monday through Thursday.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] (re)newbie py2app question

[Ned Deily]

In article 
CAJCj7-wVV5asiQuvQwxgLrti+Pv=oufkpndtynxax-gi1dd...@mail.gmail.com,
 Charles Hartman co...@conncoll.edu wrote:
 Thanks.  FWIW, I'm not using Xcode at all.  I'm aware of the 32/64 change.
  I thought I had addressed it: my Python 2.7 runs in 64-bit mode
 (sys.maxsize == 2 ** 64 yields True).  My wxPython (classic, they call
 it, for no clear reason; filename wxPython2.9-osx-2.9.3.1-cocoa-py2.7.dmg)
 purports to be friendly to either 64-bit or 32-bit.  What other API would
 be out of step?
 
 Is the fact that the program runs without error inside the Wing IDE
 debugger irrelevant?

So much for idle (not IDLE) speculation on my part.  Without more 
information, it's hard to guess and I don't have any personal experience 
with the new Cocoa-based wxPython.  Perhaps if you posted more details 
(in particular, exactly what errors you see), someone might be able to 
help.  You could also try printing the value of sys.path when you are 
running in the debugger and when not.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Fix for international characters in Tcl/Tk 8.5

[Ned Deily]

Good news for users of IDLE and other Tkinter-based applications!  A fix 
for Cocoa Tcl/Tk 8.5 for improved handling of Mac OS X input methods was 
recently applied and has now been released in the latest ActiveState Tcl 
release (8.5.11.1) available here:

http://www.activestate.com/activetcl/downloads

It appears to fix a number of long standing problems with Cocoa Tcl/Tk 
8.5 involving composite characters, like the French keyboard tilde 
(Option-N) problem and  the inability to enter Option-U + vowel to form 
umlauted vowels on US keyboards.  Entering these characters in IDLE, 
for instance, used to immediately crash Tcl and, hence, Python and IDLE.   
In fact, the Apple-supplied Tcl 8.5.9 in OS X 10.7 Lion exhibits this 
behavior (try it with /usr/bin/idle).  (The Apple-supplied TCL 8.5 in OS 
X 10.6 Snow Leopard is so buggy as to be essentially unusable with 
IDLE.)  Many thanks to Adrian Robert, Kevin Walzer, and the ActiveState 
team for addressing this nasty problem.

If you install ActiveState Tcl 8.5.x, it will automatically be used by 
the python.org 2.7.x, 3.2.x, and 3.3.x 64-bit/32-bit Pythons for OS X 
10.6 and 10.7.  It will *not* be used by the Apple-supplied system 
Pythons nor by 32-bit-only python.org Pythons.   More details here:

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

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] (re)newbie py2app question

[Ned Deily]

In article 
cajcj7-zt0ip9t7d53joenjhas4gq9_39brwegl-wtmei84n...@mail.gmail.com,
 Charles Hartman co...@conncoll.edu wrote:

 I'm just coming back to programming after years, trying to recompile an old
 program that works but needs updating and expansion.  I'm now on OS 10.6.8,
 Python 2.7.2, with wxPython (64/32bit).My newly installed py2app
 is: py2app-0.6.4-py2.7.egg.  All of these were in earlier versions when I
 last packaged the program with py2app.
 
 In Console, the errors seem to be of two kinds.  There's a long list of
 ScriptingAdditions messages about missing architectures.  Before that,
 there's this:
 [0x0-0x1bcfbce].org.pythonmac.unspecified.PyProse[87375] NameError: global
 name 'self' is not defined
 
 That seems to be in a module of the program that certainly did work before.
  I can debug the program in WingIDE, I get no problems or errors (except
 maybe the ScriptingAdditions ones) when I run it there.
 
 Have I forgotten something simple?  Has something changed that I missed?

There are significant changes in OS X 10.6 compared to earlier versions.  
The major difference is that 64-bit Intel (aka -arch x86_64) is now the 
preferred build and execution architecture.   While 32-bit Intel and 
even 32-bit PPC execution (via Rosetta emulation) are still supported, a 
64-bit/32-bit executable will, by default, run in 64-bit mode.  
Unfortunately, many older Carbon APIs are only available in 32-bit mode, 
as Apple cancelled earlier plans to make 64-bit versions of them.  
Chances are you are running into a problem with trying to use them.  You 
*may* be able to work around the problem by forcing your 64-bit/32-bit 
Python to run in 32-bit mode.  For the python.org 2.7.2, you should be 
able to do this by invoking Python as 'python2.7-32'.

Another option might be to use the 32-bit-only python.org installer but 
be aware that there will be problems using this method on OS X 10.7 Lion.

Also, life will likely be easier for you on 10.6 if you stick with Xcode 
3.2.x (still available for download from the Apple Developer Connection) 
rather than the optional Xcode 4.x releases which are also the default 
on 10.7;  the latest versions of Xcode 4.x no longer supply the 
traditional gcc-4.2 that those Pythons were built with and expect to 
find to build C extension modules.  But, if you will eventually need to 
support 10.7, you should probably dig deeper into the errors and make 
your program work in 64-bit mode as well.

Good luck!

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Ned Deily]

In article rowen-d2392e.14473313022...@news.gmane.org,
 Russell E. Owen ro...@uw.edu wrote:

 In article nad-ffa1b0.21415009022...@news.gmane.org,
  Ned Deily n...@acm.org wrote:
 
  In article rowen-acaa42.11370509022...@news.gmane.org,
   Russell E. Owen ro...@uw.edu wrote:
   I suggest you try one of these things:
   - Use gcc 4.0.1 to build extensions for 32-bit python.org python. That's 
   what I'm still doing. It requires XCode 3.x.
  
  Yes.
  
   - Use gcc 4.2.1 to build extensions for 64-bit python.org python. Two 
   issues:
  - you give up compatibility with MacOS X 10.5.
  - The result will not work with ActiveState's Tcl/Tk. Not a problem 
   for you, but both of these are unacceptable for my code.
  
  I don't understand what you mean by this.  The python.org 64-/32-bit 
  installers have a deployment target of 10.6 so will only work on 10.6 
  and 10.7 but they should work just fine with ActiveState's Tcl/Tk 8.5.x 
  on 10.6 and 10.7, just not on 10.5.  In fact, the installers are built 
  and tested on systems with A/S Tcl/Tk 8.5.x and are their use is 
  virtually required on 10.6 for any Tkinter applications due to the 
  broken state of the Apple-supplied in Tcl/Tk 8.5.x in 10.6 (the 
  Apple-supplied Tcl/Tk 8.5.x is better in 10.7 but still behind the A/S 
  version wrt critical fixes.)
  
  http://www.python.org/download/mac/tcltk/
 
 Interesting and promising. The reason I thought python.org's 64-bit 
 python was strange w.r.t. ActiveState Tcl/Tk is explained in a copy of a 
 posting I sent to the matplotlib mailing list 2011-10-12 (appended).
 
 Keven Walzer suggested the following, which now that I reread it does 
 not implicate the Python in any way, so I apologize.
 
  With Tk-Cocoa, typically you see this message when mixing libraries that 
  are linked to the system Tk in /System/Library/Frameworks/Tk.framework 
  and another installation (typically ActiveTcl) in 
  /Library/Frameworks/Tk.framework. OS X gets confused and crashes with 
  that error message.
  
  The only solution I've found is by making sure that all of your 
  Tk-linked libraries link to one location or the other. You can do this 
  by running otool -L on the relevant binaries and seeing where things are 
  linked. If you're only seeing this issue now after building matplotlib, 
  then it's logical to assume that matplotlib may have been linked to the 
  wrong library. You can change the linking by running install_name_tool 
  to get matplotlib to point to the correct version of Tk.
 
 His suggestion will almost certainly work, but it seems unfortunate to 
 have to run install_name_tool to fix the matplotlib binaries. Perhaps I 
 could have hidden the system Tcl/Tk before building matplotlib, but 
 again it seems unfortunate to need to do that.
 
 Any idea, perchance, on how to fix the underlying problem?

You *may* have run into a bug I've noticed a while back in Xcode 3.2.6.  
The Xcode installer appears to screw up the symlinks to /Library within 
/Developer/SDKs.  The net effect is that frameworks installed in 
/Library, like A/S Tcl and Tk, are not found during a build using the 
SDK as they should be.

$ cd /Developer/SDKs/MacOSX10.6.sdk/Library
$ ls -l
total 8
lrwxr-xr-x  1 root  wheel  19 Mar 17 18:24 Frameworks@ - 
/Library/Frameworks

it ends up with an extra Frameworks directory so that

/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks/Frameworks/ - 
/Library/Frameworks

The solution is to manually go in and fix the symlinks in 
/Developer/SDKs/MacOSX10.6.sdk, and remember to do so again if you have 
to reinstall Xcode 3.2.6.  AFAIK, this bug is unique to Xcode 3.2.6, not 
earlier versions of 3.2.x.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyCon..

[Ned Deily]

In article b606eef9-afc0-4759-a8d3-b906a3f12...@mac.com,
 Ronald Oussoren ronaldousso...@mac.com wrote:

 On 13 Feb, 2012, at 20:35, Chris Barker wrote:
 
  Hi folks,
  
  PyCon is in Santa Clara CA, USA in March this year.
  
  At least Ned and I will be there -- do we have enough Mac folks to do
  a MacPython sprint?
 
 I'll be there as well, but won't sprint this year.

I'm planning to sprint through Thursday.   I've added a Mac OS X Support 
project to the PyCon sprint page.  Feel free to add topics and add 
yourself.  Hope to see you all there!

https://us.pycon.org/2012/community/sprints/projects/

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Ned Deily]

In article rowen-7e9d15.12573914022...@news.gmane.org,
 Russell E. Owen ro...@uw.edu wrote:
 My symlinks are broken as you describe (though oddly 
 /Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks contains both the 
 symlink Frameworks-Library/Frameworks that you mentioned and also 
 PluginManager.framework).
 
 I'll fix it and try building matplotlib again. Thank you very much!

Glad it helped.  I've opened Issue14018 to add a check to the OS X 
installer build script to make sure that tkinter is linked as expected 
with the A/S frameworks.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Ned Deily]

In article rowen-acaa42.11370509022...@news.gmane.org,
 Russell E. Owen ro...@uw.edu wrote:
 I suggest you try one of these things:
 - Use gcc 4.0.1 to build extensions for 32-bit python.org python. That's 
 what I'm still doing. It requires XCode 3.x.

Yes.

 - Use gcc 4.2.1 to build extensions for 64-bit python.org python. Two 
 issues:
- you give up compatibility with MacOS X 10.5.
- The result will not work with ActiveState's Tcl/Tk. Not a problem 
 for you, but both of these are unacceptable for my code.

I don't understand what you mean by this.  The python.org 64-/32-bit 
installers have a deployment target of 10.6 so will only work on 10.6 
and 10.7 but they should work just fine with ActiveState's Tcl/Tk 8.5.x 
on 10.6 and 10.7, just not on 10.5.  In fact, the installers are built 
and tested on systems with A/S Tcl/Tk 8.5.x and are their use is 
virtually required on 10.6 for any Tkinter applications due to the 
broken state of the Apple-supplied in Tcl/Tk 8.5.x in 10.6 (the 
Apple-supplied Tcl/Tk 8.5.x is better in 10.7 but still behind the A/S 
version wrt critical fixes.)

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

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Ned Deily]

In article 
CALGmxEJVLD6fvUTxzhm3DfNDCLGC8wH_-UY-hGOOPF=qy9c...@mail.gmail.com,
 Chris Barker chris.bar...@noaa.gov wrote:

 On Thu, Feb 9, 2012 at 11:37 AM, Russell E. Owen ro...@uw.edu wrote:
 
  I suggest you try one of these things:
  - Use gcc 4.0.1 to build extensions for 32-bit python.org python. That's
  what I'm still doing. It requires XCode 3.x.
 
 Thanks -- Ill try that. but:
 
 1) I thought distutils took care of calling the right compliler to
 match what pyotn had been built with. I guess not.

Distutils *does* try to call the right CC compiler (that is, the 
compiler the Python itself was built with), unless the 
module/package/distribution's setup.py overrides it.  If it is using C++ 
code, though, you may have to override that yourself since Python itself 
does not contain any C++ code and I don't think there is any special 
code in Distutils to override C++ stuff.
 
 2) how do I use 4.01. with distutils?

For the any C++ modules, you may need to override the C++ compiler 
choice by using a CXX environment variable.

What OS version are you trying this on, BTW?

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] New to list with issues

[Ned Deily]

In article df60a24f-77ec-4832-bff4-09320a746...@roontoon.com,
 Daniel Rahenkamp dk...@roontoon.com wrote:

 On Dec 29, 2011, at 6:00 AM, pythonmac-sig-requ...@python.org wrote:
  
  I am new to the list and of course I have issues... I have run into a 
  problem of which I find that I am a bit out of my depth in solving. I have 
  upgraded to lion and python 2.7.2 and I have several scripts that I have 
  been running for over a year as dameons are now crashing with errors that 
  I cannot interpret. Any help will be GREATLY appreciated as I am dead in 
  the water in terms of using Python. Below is the error and full problem 
  report. Thanks so much.
  
  Apple's crash report is probably useless (but maybe there are greater 
  wizards than me on this list that can make any sense from it) - try to get 
  a proper Python traceback!
  Maybe it's in the console.log
  Did you try to run your scripts on the command line, i.e. not as daemons?
  Can you show us (parts of) the scripts? Probably there are modules missing.
  Did you run from a system Python before?
 
 
 
 Thanks for the reply. This is weird because Python does not fully crash but 
 periodically it will throw the error I included in my last post but the 
 script is still working. When looking in the console there are multiple 
 entries with Python_current date.mini_crash with the same system crash 
 report that I included. In this test I ran the app from the command line and 
 not as a daemon but the results are the same. When I have tried python 2.6 on 
 the same machine things run fine. The problem seems to be with the apple 
 included 2.7 that came with Lion. Lastly I am not sure what you mean by run 
 from a system Python before Here is a screen shot of the console messages 
 http://screencast.com/t/qDjnMb3KYS Thanks so much.

From the traceback, it appears that there is a problem with Python's 
_scproxy module; that's an internal helper C module that provides an 
interface to the OS X System Configuration framework to access Internet 
proxy configurations for the urllib module.  You should open an issue 
for this at bugs.python.org.  Please include the original crash report 
traceback.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Which version of python on OSX Lion 10.7.2

[Ned Deily]

In article 025d9d55-e4bd-4602-ae93-d42081f22...@gmail.com,
 Erik van Blokland letter...@gmail.com wrote:

 Hi all,
 
 I'm writing some code intended to help installing some python modules on OSX. 
 There are some complications outside my control (that I hope I won't have to 
 go into) that make it a bit of a puzzle.
 
 The installer is targeted at Python 2.7.1 on OSX Lion 10.7.2, and this has an 
 accessible site-packages folder at
   /Library/Python/2.7/site-packages
 
 While trying my installer on different machines (MacBook, MacBook Pro, iMac) 
 running Lion (OSX 10.7.2, build 11C74), most of the python versions I see 
 are:
  Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
  [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on 
  darwin
 
 I came across a new MacBook Pro, OSX 10.7.2, also build 11C74. This one had 
 another one:
  Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 14:13:39) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
 
 This machine is brand new and hasn't had any post-unpacking installations. 
 This 2.7.2 also looks at  
   /Library/Python/2.7/site-packages
 ..which is helpful, but this version doesn't have any of the OSX modules, no 
 objc or AppKit.
 
 Any other users with a similar experience? Is the 2.7.2 somehow a freak 
 version, or are there really multiple versions floating around?

The objc and AppKit modules are provided by Apple and so are only 
available in the system Pythons.  They should always be available 
regardless of whether a user installs other Pythons, which they often do 
since Apple never updates system Pythons (other than the occasional 
security fix).  If you are installing something that depends on the 
system Python, you should explicitly invoke Python via 
/usr/bin/python2.7 and, if you need to use easy_install, 
/usr/bin/easy_install-2.7

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python 2.7 (Lion) and user site-packages folder problem

[Ned Deily]

In article 
CANDJYq+HEqzMs541rV8ebm=3rhyqouejohysy6lbxvlvteq...@mail.gmail.com,
 Hamid M. spam@gmail.com wrote:
 When I make Apple-supplied python-2.7 the default python on my system,
 it ignores my local site-packages folder in ~/Library/Python/2.7/site-packges
 This does not happen when using 2.6!
 Is this behavior expected ? How can I permanently add that folder to
 my sys.path?

For 2.7 (and 3.2), the location moved with the changes for Issue8084.   
Those changes proved somewhat controversial and so there is an as-yet 
unresolved issue about the location(s) for local site-packages on OS X 
(see also Issue7175).  This will eventually get resolved before Python 
3.3 releases.  In the meantime, try:

~/Library/Python/2.7/lib/python/site-packages/

You should also be able to create a symlink to make the old and the new 
locations equivalent.

http://bugs.python.org/issue8084
http://bugs.python.org/issue7175

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] installation trouble

[Ned Deily]

In article blu0-smtp133c2a88bf0e45a93ccf2d3c3...@phx.gbl,
 Paul Patterson paz...@hotmail.com wrote:

 I'm trying to install py-appscript to work with Python 3.1. My first attempt
 didn't exactly fail, rather py-appscript installed itself to work with the
 version of Python pre-installed on my computer (Python 2.6 on macbook pro
 running snow leopard). In an effort to get it working with 3.1, I then
 downloaded distribute 0.6.19 and appscript 1.0, moved them both to the
 directory where python 3.1 is installed. I installed distribute then tried
 to install appscript. After spewing out a ton of error messages, it ended
 with the line 
 error: command 'gcc-4.0 failed with exit status 1.
 
 Thinking it maybe had something to do with gcc (though I've no idea what gcc
 is), I ran the command:
 export CC=/usr/bin/gcc-4.0
 Unfortunately It still didn't work and returned another error message (see
 attachment for screenshot).
 
 Can anyone tell me what my next step should be?

If you are using a python.org Python 3.1 and have installed Distribute 
properly, you should be able to use it by ensuring that the Python 3 bin 
directory is on your shell PATH.  One way to do that, temporarily for 
one terminal session, is to enter the following:

export PATH=/Library/Frameworks/Python.framework/Versions/3.1/bin:$PATH

then you should be able to install Appscript with:

easy_install-3.1 appscript

Because py-appscript includes a C extension module, you need to ensure 
that you have the Apple Developer Tools package (aka Xcode) installed.  
For OS X 10.6 (Snow Leopard) there are two versions of Xcode available: 
the original Xcode 3 which should have come with your Mac's install DVD 
or with the retail copy of Snow Leopard.  If not, it can be downloaded 
(after free registration) from the Apple Developer Connection website.  
There is also a newer Xcode 4, which is somewhat experimental for Snow 
Leopard but is standard on OS X 10.7, Lion.

Be aware that Python 3.1 is already obsolete and in security fix mode 
only.  Python 3.2.1 is current and 3.2.2 is scheduled to be released 
this weekend.  If you are using the standard python.org Python 3.1 
installer, you will likely have problems installing packages like 
appscript if you have installed Xcode 4 and you will definitely have 
problems if you upgrade to Lion.  For all of these reasons unless you 
have a specific need to stick with 3.1, I would strongly urge you to, 
instead, install the latest 64-bit/32-bit installer for Python 3.2 (a 
3.2.2 installer should be available by Monday or so):

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

That will work fine with either Xcode 3 or Xcode 4 and either Snow 
Leopard or Lion.  You'll need to reinstall Distribute for it.  And just 
change the 3.1 to 3.2 in the export command above.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] translate applescript to appscript

[Ned Deily]

In article 
CAGMDJTvP7aFAa05Q4tygSrt1E2H9f9kSmbGfQq25X=252zn...@mail.gmail.com,
 Adam Morris amor...@mistermorris.com wrote:
   app(Finder).items[mactypes.Alias(/path/to/file)]
 It works! Thanks!!
 (So simple, actually)

It is simple but not necessarily obvious.  I've been using appscript for 
a number of years but it was just fairly recently that I ran across that 
reference form somewhere.  Perhaps we can persuade HAS to add an example 
to the appscript documentation.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] translate applescript to appscript

[Ned Deily]

In article 
CAGMDJTuDHeiGK2CZ7iRx_hP+ahbktR=yhtzvuv3mycwdeyq...@mail.gmail.com,
 Adam Morris amor...@mistermorris.com wrote:
 I posted a question a few months ago and didn't quite get the answer I
 was looking for, so this is my second attempt.
 
 I need the following applescript translated into python appscript:
 
 tell application Finder to /path/to/file as POSIX file as alias
 
 The earlier answer given was:
 
 mactypes.Alias(/path/to/file)
 
 But this is not sufficient, because I'm looking for the Finder
 reference form, and it seems that mactypes.Alias returns an alias
 reference form (See here for context on those terms:
 http://macscripter.net/viewtopic.php?id=24575)
 
 The ugly solution I'm using now is to manually build the Finder
 reference form by parsing the string (folder('path').folder('to')),
 and this is not sufficient either, because there are folders (such as
 the /tmp folder) that are not visible to the Finder and so fail.

Try this reference form:

  app(Finder).items[mactypes.Alias(/path/to/file)]

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Ownership of installed Python on Mac

[Ned Deily]

In article 
CAKCKLWxR4Ubyh4sQJoyuan7=jfdzx62trafvhenc6udpuec...@mail.gmail.com,
 Michael Foord fuzzy...@gmail.com wrote:
 I've installed Python on OS X Lion on two computers - one with Lion
 preinstalled and one upgraded from Snow Leopard. I used both Python.org and
 Activestate installers.
 
 In all cases (I'm pretty sure) the installation required elevation and the
 installed Python was 'owned' by root - meaning any changes (e.g.
 installation into site-packages) must be sudo'd.
 
 This is a change from previous versions of OS X. Is this known, and is it an
 issue? (I chown'd everything back to me to get round it.)

I can't speak to the ActiveState installer but for the python.org 
installers installation has always required a username with 
administrator privilege.  That hasn't changed in Lion.  And, even though 
owned by root, when logged in via an admin username, you should be able 
to install packages to its default location (using python setup.py or 
easy_install or pip) without sudo.  The default site-packages directory 
for python.org installations is:

cd /Library/Frameworks/Python.framework/Versions/x.y/
ls ./lib/pythonx.y/site-packages
ls ./bin   # for scripts

If you are using easy_install, make sure you aren't using the 
Apple-supplied easy_installs in /usr/bin which are for the system 
Pythons (2.7, 2.6, and 2.5 in OS X 10.7).  They will, by default, 
attempt to install into /Library/Python/2.y and /usr/local/bin for 
scripts and that *does* need sudo.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Ownership of installed Python on Mac

[Ned Deily]

In article nad-758d69.12421609082...@dough.gmane.org,
 Ned Deily n...@acm.org wrote:

 In article 
 CAKCKLWxR4Ubyh4sQJoyuan7=jfdzx62trafvhenc6udpuec...@mail.gmail.com,
  Michael Foord fuzzy...@gmail.com wrote:
  I've installed Python on OS X Lion on two computers - one with Lion
  preinstalled and one upgraded from Snow Leopard. I used both Python.org and
  Activestate installers.
  
  In all cases (I'm pretty sure) the installation required elevation and the
  installed Python was 'owned' by root - meaning any changes (e.g.
  installation into site-packages) must be sudo'd.
  
  This is a change from previous versions of OS X. Is this known, and is it an
  issue? (I chown'd everything back to me to get round it.)
 
 I can't speak to the ActiveState installer but for the python.org 
 installers installation has always required a username with 
 administrator privilege.  That hasn't changed in Lion.  And, even though 
 owned by root, when logged in via an admin username, you should be able 
 to install packages to its default location (using python setup.py or 
 easy_install or pip) without sudo.  The default site-packages directory 
 for python.org installations is:
 
 cd /Library/Frameworks/Python.framework/Versions/x.y/
 ls ./lib/pythonx.y/site-packages
 ls ./bin   # for scripts
 
 If you are using easy_install, make sure you aren't using the 
 Apple-supplied easy_installs in /usr/bin which are for the system 
 Pythons (2.7, 2.6, and 2.5 in OS X 10.7).  They will, by default, 
 attempt to install into /Library/Python/2.y and /usr/local/bin for 
 scripts and that *does* need sudo.

Just to clarify:  to install Python itself using a python.org installer 
requires entering an admin user name and password using the standard OS 
X GUI installer or sudo installer if using the command line OS X 
installer.  But if you are running under a user with admin priv you 
shouldn't need to use sudo to install Distutils-based packages (via 
setup.py, easy_install, etc) with the python.org installed Pythons.  As 
far as I know, there is no difference in this behavior between Lion, 
Snow Leopard, or Leopard.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Ownership of installed Python on Mac

[Ned Deily]

In article 
CAKCKLWwbY2DAywF=f_k=h9ovkhjjq+prkng60q9d5xte+vg...@mail.gmail.com,
 Michael Foord fuzzy...@gmail.com wrote:

 On 9 August 2011 20:42, Ned Deily n...@acm.org wrote:
 
  In article
  CAKCKLWxR4Ubyh4sQJoyuan7=jfdzx62trafvhenc6udpuec...@mail.gmail.com,
   Michael Foord fuzzy...@gmail.com wrote:
   I've installed Python on OS X Lion on two computers - one with Lion
   preinstalled and one upgraded from Snow Leopard. I used both Python.org
  and
   Activestate installers.
  
   In all cases (I'm pretty sure) the installation required elevation and
  the
   installed Python was 'owned' by root - meaning any changes (e.g.
   installation into site-packages) must be sudo'd.
  
   This is a change from previous versions of OS X. Is this known, and is it
  an
   issue? (I chown'd everything back to me to get round it.)
 
  I can't speak to the ActiveState installer but for the python.org
  installers installation has always required a username with
  administrator privilege.  That hasn't changed in Lion.  And, even though
  owned by root, when logged in via an admin username, you should be able
  to install packages to its default location (using python setup.py or
  easy_install or pip) without sudo.
 
 
 I don't believe that is actually the case in Lion due to the changes pointed
 out by Nicholas.

Odd!  So far, this works for me on Lion with the current python.org 
installer (3.2.1 at least).  Perhaps you can be more specific about 
exactly how to reproduce what has changed for you.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Ownership of installed Python on Mac

[Ned Deily]

In article nad-12dcdd.14311109082...@news.gmane.org,
 Ned Deily n...@acm.org wrote:

 In article 
 CAKCKLWwbY2DAywF=f_k=h9ovkhjjq+prkng60q9d5xte+vg...@mail.gmail.com,
  Michael Foord fuzzy...@gmail.com wrote:
  I don't believe that is actually the case in Lion due to the changes 
  pointed
  out by Nicholas.
 Odd!  So far, this works for me on Lion with the current python.org 
 installer (3.2.1 at least).  Perhaps you can be more specific about 
 exactly how to reproduce what has changed for you.

Ah, a thought!  I have been testing with a vanilla Lion system with a 
freshly-installed python.org Pythons.  In that case, the permissions of 
the files in /Library/Frameworks/Python.framework are being set as 
specified by the python.org installer.  Perhaps you are using a 
python.org Python that was on a system upgraded from Snow Leopard?  In 
that case, the Apple upgrade process may have mucked with the 
permissions of the existing files.  Reinstalling using the python.org 
installers would likely take care of that.  But it is something we 
should document and or consider changing.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Ownership of installed Python on Mac

[Ned Deily]

In article nad-8cf749.14423009082...@news.gmane.org,
 Ned Deily n...@acm.org wrote:

 In article nad-12dcdd.14311109082...@news.gmane.org,
  Ned Deily n...@acm.org wrote:
 
  In article 
  CAKCKLWwbY2DAywF=f_k=h9ovkhjjq+prkng60q9d5xte+vg...@mail.gmail.com,
   Michael Foord fuzzy...@gmail.com wrote:
   I don't believe that is actually the case in Lion due to the changes 
   pointed
   out by Nicholas.
  Odd!  So far, this works for me on Lion with the current python.org 
  installer (3.2.1 at least).  Perhaps you can be more specific about 
  exactly how to reproduce what has changed for you.
 
 Ah, a thought!  I have been testing with a vanilla Lion system with a 
 freshly-installed python.org Pythons.  In that case, the permissions of 
 the files in /Library/Frameworks/Python.framework are being set as 
 specified by the python.org installer.  Perhaps you are using a 
 python.org Python that was on a system upgraded from Snow Leopard?  In 
 that case, the Apple upgrade process may have mucked with the 
 permissions of the existing files.  Reinstalling using the python.org 
 installers would likely take care of that.  But it is something we 
 should document and or consider changing.

Yes, reinstalling Python using the python.org installer fixes it because 
the installer's post-install script simply does a chgrp -R admin and 
chgrp -R g+w to the version it installed.  That should be 
non-destructive, i.e. existing packages installed in site-packages 
should not disturbed so, if a user is not comfortable with the command 
line, reinstalling with a python.org installer after an upgrade to Lion 
is viable.  Also, because the permissions are set this way rather than 
explicitly in an installer bom, the Disk Utility.app (or diskutil) 
Repair Permissions function doesn't help for this.

On my high-priority list of things to do is to update the Using Python 
on a Macintosh section of the Python Setup and Usage standard doc as 
well as http://www.python.org/download/mac/ both of which are very 
out-of-date.  There is the new http://www.python.org/download/mac/tcltk/ 
which I have been keeping up-to-date.  Somewhere in there or in the wiki 
should be a section on upgrading which could include things like this.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Lion

[Ned Deily]

In article rowen-b7bd6d.12105422072...@news.gmane.org,
 Russell E. Owen ro...@uw.edu wrote:

 In article bd2a3e7e-aaad-42b9-a310-0b981498f...@mac.com,
  Ronald Oussoren ronaldousso...@mac.com wrote:
 
  On 22 Jul, 2011, at 6:10, Aahz wrote:
  
   On Thu, Jul 21, 2011, Ned Deily wrote:
   
   Although it's not practical to build packages with C extension modules 
   on 10.7 for the traditional 32-bit-only python.org Pythons (as explained 
   above), it is possible to build such packages with the same Python 
   installed on a 10.6, 10.5, or even 10.4 system, create a Distutils bdist 
   or setuptools/Distribute bdist-egg and then install the binary 
   distribution on the 10.7 system.  I would avoid going down that path if 
   possible, unless it is needed as a temporary transition phase.
   
   Why?  Isn't that the only way to get a multi-platform build?
  
  It is the only way to get a build that works with PPC systems, with some 
  care
  you can binaries on 10.7 that work just fine earlier releases.
  
  To create binaries that work on 10.5 (or even 10.4) you'll need a new
  python install though, the Intel-only installer on python.org only supports
  10.6 or later due to the Tkinter dependency.
  
  The hardest  part w.r.t. binaries that run on earlier versions is that C 
  software
  that uses a configure script might detect features on your build system
  that aren't available on earlier releases.
  
  Ronald
 
 Rob Manegan suggested another approach that I am considering: install 
 the older SDKs on XCode 4.1.
 
 I found a link that provides clear instructions:
 http://hints.macworld.com/article.php?story=20110318050811544
 
 Personally I'm happy to ditch PPC and MacOS X 10.4, but I'm not in a 
 position to abandon MacOS X 10.5 users yet. However, from what you said 
 it sounds as if the only way to build extensions with the 32-bit 
 python.org python is to install the 10.4/ppc support.
 
 So I think my options (since I need to distribute an app that can run on 
 10.5 and later) are:
 - Install 10.4 support in XCode 4.1, as above. The main annoyance with 
 this is the need to stay at gcc 4.0.

Note those instructions were for installing both Xcodes on 10.6, not 
10.7, and before Xcode 4.1 was released.  So be cautious.  But it should 
be possible to make it work on 10.7.  But, of course, it's not something 
to recommend for the casual user.

Also, IIRC, the big main reason we stayed with gcc-4.0 and the 10.4u SDK 
was that the 10.5 SDK did not support the PPC G3 machines (like the 
Pismo) which are supported by 10.4 (but not 10.5).  If you don't need to 
support them, you may be able to get by with the 10.5 SDK.

As it stands, the current 32-bit-only python.org installers will work on 
any Apple machine that was supported to run 10.3.9 through 10.7 
(excluding the issue of extension building on 10.7 and probably 10.3 as 
well). 

 - Build extensions on 10.6 or earlier. This is not a big deal because 
 keep an old laptop around for this purpose due to unresolved backward 
 compatibility issues building matplotlib and PIL binaries on 10.6.

This is probably the safest option.

 - Switch to ActiveState Python (since they offer a 10.5-and-later python 
 and python.org sadly does not) or build my own. This involves a bit of 
 licensing headache as I have to renew a free license every year.

Again, as long as you don't mind ditching 10.5 PPC users as the A/S 
Python distribution is Intel only, I believe.

We discussed having a python.org 10.5+ 64-bit/32-bit installer; in fact, 
there was a 3-way universal for the original 2.7 release.  But that was 
before there was a reasonable 64-bit Tk solution which unfortunately 
does not include PPC.  We could look at going back to that for future 
releases but I think it is not a good idea at this point.  There are 
other differences between 10.5 and 10.6 (missing API's, older libraries, 
etc); it would mean either not supporting some of the machines that can 
run 10.5 (PPC); and 10.6 is a much cleaner dividing line, IMO.  That is, 
from the perspective of what Python needs from OS X, the gap between 
10.5 and 10.6 is much wider than that between 10.6 and 10.7.   We also 
have some important new options to explore for future releases, like 
moving from gcc to clang, among many other things.  Given our very 
limited development and testing resources, I think the time is better 
spent looking to the future than more work on the past.  For future 
releases (next year's 3.3 for instance), we'll need to look closely at 
just what we claim to support in the form of installers.  Certainly, we 
won't want to break or remove support in the source for existing older 
platforms (10.3.9+) but clearly their importance is fading.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app application fails with ImportError: No module named sysconfig

[Ned Deily]

In article 280edc66-be30-455f-a9fc-80349c6d5...@uw.edu,
 Russell Owen ro...@uw.edu wrote:

 On Jul 20, 2011, at 3:31 PM, Russell E. Owen wrote:
 
  I used py2app to build an application that i've been building for years, 
  only now it's failing at startup with the appended log.
  
  The problem is triggered by numpy 1.6.1fc3 (which I installed from 
  source). If I build using an older numpy I don't see the problem.
  
  However, the application runs just fine from the command line, so I'm 
  puzzled how it could be an actual bugin numpy. (If it is, though, now is 
  a great time to report it, before 1.6.1 is released).
  
  Any idea what might be causing this and how to avoid it? A google search 
  didn't turn up anything that looked relevant. 
  
  -- Russell
 
 For some reason 1.6.1 release does not exhibit this problem. I tried the 
 32-bit binary installer and also installing from source and in both cases the 
 application runs just fine.
 
 I verified yet again that 1.6.1rc3 shows the problem (by building it yet and 
 then my app yet again). For every test I always delete numpy from 
 site-packages before installing the next version.
 
 I don't know what happened with 1.6.1rc3, but I'm very relieved the bug is 
 gone in 1.6.1 release.
 
 For those who are curious there are only four python files that are different 
 between 1.6.1rc3 and 1.6.1 release (according to bbdiff). Of these the only 
 change I can even imagine is relevant is this one:
 
 numpy/ctypeslib.py changes when this line is called (1.6.1rc3 did it right 
 away; 1.6.1 moves it into the code);
from numpy.distutils.misc_util import get_shared_lib_extension
 
 The others are:
 - numpy/polynomial/polytemplate.py one __str__ method and one __repr__ method 
 changed
 - numpy/version.py: only version data changed
 - setup.py: only version data changed

Ah, I hadn't noticed this in the traceback you initially posted but it 
appears that numpy has its own package named distutils that apparently 
supplants the normal Python distutils.  That seems rather error prone! 
There are some differences in the latest Python 2.7 with how and when 
the real distutils.sysconfig is called.  No doubt the change that moves 
the from numpy.distutils.misc_util import solves an import ambiguity 
somewhere so that the normal distutils.sysconfig is found and imported 
earlier.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Lion

[Ned Deily]

In article nad-adc32d.17270820072...@news.gmane.org,
 Ned Deily n...@acm.org wrote:
 The 64-bit/32-bin python.org installers (current releases are 3.2.1 and 
 2.7.2) *should* work on 10.7 Lion.  I'm not so sure about the 
 traditional 32-bit-only ones (the 10.3+ ones). As with 10.6, I expect 
 you will need to install ActiveState Tcl/Tk 8.5 if you want to use 
 Tkinter or IDLE as there have been some recent fixes for Cocoa Tk.   I 
 just have completed downloading the official 10.7 release and should 
 have some preliminary results posted by tomorrow.

Here's my take on things after installing and some quick testing with 
10.7 Lion:

- If you were satisfied with using the Apple-supplied Pythons in 
previous OS X releases, you'll probably be satisfied with the 2.7, 2.6, 
or 2.5 system Pythons in 10.7.

- You should not rely on the Apple-suppled Pythons if you want to use 
IDLE.
   http://www.python.org/download/mac/tcltk/

- If you prefer to use more recent Pythons and have been satisfied with 
python.org OS X installers, use the most recent 3.2.1 or 2.7.2 
64-bit/32-bit (x86-64 / i386) installers for Mac OS X:
   http://www.python.org/download/
As with 10.6, if you are planning to use IDLE or Tkinter with these 
installers, you should also install the most recent ActiveTcl 8.5 if you 
can (check the license terms):
   http://www.activestate.com/activetcl/downloads

- If you need to install any Python packages that build C extension 
modules, you'll need to install Xcode for Lion (currently 4.1 and now 
available for free download through the Mac App store).

- The traditional python.org 32-bit-only 10.3+ (i386/PPC) Pythons can be 
installed on 10.7 and do work in general; however, it is not practical 
to build C extension modules on 10.7 that will work with them (since 
Xcode 4 no longer includes the 10.4u SDK nor gcc-4.0).  Unless you have 
specialized needs and know what you are doing, you should avoid using 
the traditional 32-bit-only installers on 10.7 in favor of either using 
the 64-bit/32-bit variants, using versions from a different distributor, 
or building your own.  As on 10.6, if you need to run in 32-bit mode, 
you can use python3.2-32 or python2.7-32 with the 64-bit/32-bit 
variants.



Random details:

Apple ships 10.7 with 3 system Pythons:

/usr/bin/python2.7
Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on 
darwin
/usr/bin/python2.6
Python 2.6.6 (r266:84292, Jun 16 2011, 16:59:16) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on 
darwin
/usr/bin/python2.5
Python 2.5.5 (r255:77872, Jun 16 2011, 16:58:16) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on 
darwin

The 2.7 and 2.6 instances are 2-way Intel universal binaries (x86_64 and 
i386); the 2.5 one is i386 (32-bit) only.  The 2.7 version, at least, 
comes pre-installed with various 3rd-party packages, like setupttols, 
PyObjC, py2app, numpy, twisted, Zope, etc, similar to what was shipped 
for 2.6 in 10.6.  (I didn't look at the 2.6 and 2.5 frameworks.)  The 
downside of shipping these packages is that some, including Python 
itself, are not the latest versions.

Tcl/Tk:  As in 10.6, Apple ships two versions of Tcl/Tk: a Cocoa Tk 8.5 
and the venerable Carbon Tk 8.4.  The 8.5 version has been updated to 
8.5.9.  The Tkinters in all three Apple-supplied Pythons are linked with 
8.5.  The good news is that the updated 8.5 is not the disaster that the 
10.6 version was.  The bad news is that it is missing at least one fix 
to Tk from earlier this year:
Cocoa Tk crashes when typing a composite character into a text field 
(http://sourceforge.net/tracker/index.php?func=detailaid=2907388group_i
d=12997atid=112997).  The fix for this crash is incorporated into the 
most recent ActiveTcl 8.5 releases for OS X.  However, the system 
Pythons will not attempt to dynamically link to user-installed Tcl/Tk 
frameworks in /Library (where the ActiveState frameowrks are installed), 
unlike the Pythons installed by python.org installers.  So, out of the 
box, the IDLE versions that come with the system Pythons are vulnerable 
to this.  But at least they aren't totally unusable as was the case with 
10.6.  And I suppose if there are enough bug reports this fix might get 
applied in a future 10.7 update.

Although it's not practical to build packages with C extension modules 
on 10.7 for the traditional 32-bit-only python.org Pythons (as explained 
above), it is possible to build such packages with the same Python 
installed on a 10.6, 10.5, or even 10.4 system, create a Distutils bdist 
or setuptools/Distribute bdist-egg and then install the binary 
distribution on the 10.7 system.  I would avoid going down that path if 
possible, unless it is needed as a temporary transition phase.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http

Re: [Pythonmac-SIG] Lion

[Ned Deily]

In article c3f76eda-e6cd-4f97-8abf-a770f5a4c...@rosspixelworks.com,
 Dan Ross d...@rosspixelworks.com wrote:

 Installing python.org's framework should work shouldn't it?

The 64-bit/32-bin python.org installers (current releases are 3.2.1 and 
2.7.2) *should* work on 10.7 Lion.  I'm not so sure about the 
traditional 32-bit-only ones (the 10.3+ ones). As with 10.6, I expect 
you will need to install ActiveState Tcl/Tk 8.5 if you want to use 
Tkinter or IDLE as there have been some recent fixes for Cocoa Tk.   I 
just have completed downloading the official 10.7 release and should 
have some preliminary results posted by tomorrow.

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

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app application fails with ImportError: No module named sysconfig

[Ned Deily]

In article rowen-efd413.16170920072...@news.gmane.org,
 Russell E. Owen ro...@uw.edu wrote:

 In article rowen-19af14.15315420072...@news.gmane.org,
  Russell E. Owen ro...@uw.edu wrote:
 
  I used py2app to build an application that i've been building for years, 
  only now it's failing at startup with the appended log.
  
  The problem is triggered by numpy 1.6.1fc3 (which I installed from 
  source). If I build using an older numpy I don't see the problem.
  
  However, the application runs just fine from the command line, so I'm 
  puzzled how it could be an actual bugin numpy. (If it is, though, now is 
  a great time to report it, before 1.6.1 is released).
  
  Any idea what might be causing this and how to avoid it? A google search 
  didn't turn up anything that looked relevant. 
 
 To follow up on this, I have tested the following configurations (MacOS 
 X 10.6.8 with MACOSX_DEPLOYMENT_TARGET=10.4):
 
 build numpy 1.6.1fc3 from source: the only case that shows a problem. I 
 built this numpy twice and both times saw the problem.
 
 The following did not show the problem:
 build numpy 1.5.1 from source
 install numpy 1.5.1 using binary installer
 install numpy 1.6.0 using binary installer
 
 I also noticed that the module with the failing import 
 (distutils/ccompiler.py) is identical in numpy 1.5.1 and 1.6.1fc3.

What version of Python 2.7 are you using?  And, if you built it 
yourself, what ./config options did you use?

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python virtual environments on OS X

[Ned Deily]

In article loom.20110718t185416-...@post.gmane.org,
 Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
 I'm working on pythonv[1], a branch which aims to bring virtual environment
 creation functionality into Python itself (work on a PEP is in progress).
 
 I've got a prototype working quite well on Linux and Windows [2], but not yet
 done any work on OS X.
[...]
 My question is, will this approach work on OS X? I can't readily build and 
 test
 on an OS X system at the moment, so I'm hoping someone can enlighten me. If a
 python executable file has sys.prefix/sys.exec_prefix pointing to a framework
 build's location, will that give the virtual environment everything it needs
 to e.g. interface to Cocoa etc? Or does any other setup need to be done?
 [1] https://bitbucket.org/vinay.sajip/pythonv/
 [2] http://www.red-dove.com/screencasts/pythonv/pythonv.html

Vinay:

I did a quick build and test using a non-default framework location and 
the virtual env set up by ./python -m virtualize test_dir worked just 
fine, just as the original virtualenv does with framework builds.  So 
while we may find some nits down the road, I think the general approach 
is fine.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app zlib import error

[Ned Deily]

In article BANLkTi=rqswtbkbqwgr+sgb8xr-kxfb...@mail.gmail.com,
 Brian Zambrano bri...@gmail.com wrote:

  ls -l ./Resources/lib/python2.6/lib-dynload/zlib.so
[...]

Sorry, nothing obviously wrong there.  So presumably it is some sort of 
path issue in the py2app bootstrap.  Hope you track it down.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app zlib import error

[Ned Deily]

In article banlktiku6mtem1o_ma5hfgbu4bzsc4b...@mail.gmail.com,
 Brian Zambrano bri...@gmail.com wrote:

 Just bumping this.  Does anyone have solution or some advice on how to
 proceed?

You might be able to provide more insight by running the following 
commands on the zlib extension module:

ls -l ./Resources/lib/python2.6/lib-dynload/zlib.so
file ./Resources/lib/python2.6/lib-dynload/zlib.so
otool -L ./Resources/lib/python2.6/lib-dynload/zlib.so

and stating exactly which py2app options you are using to build the app.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] OSX 10.5 and 64-bit Python

[Ned Deily]

In article banlktimvayvw7shh866kfiig9hsyw5b...@mail.gmail.com,
 Chris Weisiger cweisi...@msg.ucsf.edu wrote:

 Is there a readily-installable 64-bit Python for OSX 10.5? python.org only
 has 64-bit for 10.6, and while my searches have turned up instructions (of
 greater or lesser complexity) for building it from scratch, I'd rather use a
 vetted install if possible. Moreover, I'm eventually going to py2app this
 thing, and I'd rather not restrict my userbase based on their operating
 system version.

There is none from python.org.  If you intend to only provide a 
64-bit-only version of your app, that will, of course, exclude a 
significant portion of 10.5 and 10.6 users, i.e. those with earlier 
32-bit-only Intel processors and (for 10.5) PPC users.  And that's the 
main reason why such a configuration isn't provided on python.org.  The 
32-bit-only Pythons provided there will run on all Macs that run 10.3.9 
through 10.6.

If you do need 64-bit, it is possible to build a 10-5+ universal 
version.  I'd suggest looking at the Mac/BuildScript README.txt and 
build-installer.py script in the Python source tree.   The relevant 
option to the installer script is --universal-archs.  The current top of 
trunk for 2.7.x is here (and these files are more up-to-date than the 
2.7.1 released versions):

http://hg.python.org/cpython/file/76a2354aa427/Mac/BuildScript

You'd have to tweak the script a bit to get *just* 64-bit Intel, if you 
need that.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] improving interactivity in scripts

[Ned Deily]

In article 0bdad7f3-dc82-425c-ad8f-86b1a2eb3...@letterror.com,
 Erik van Blokland e...@letterror.com wrote:

 On 4 mei 2011, at 11:41, Adam Morris wrote:
 
  Could you suggest a package or different packages to use to get me
  things like checkboxes in my simple dialog boxes that also ask for
  input?
 
 I've found the Vanilla library easy to work with to build simple dialogs, but 
 more complex stuff as well. 
 http://code.typesupply.com/wiki/Vanilla

There's also the venerable CocoaDialog:

http://cocoadialog.sourceforge.net/

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Extension module compile fail, due to isysroot param pointing to sdk without certain headers. Any tips?

[Ned Deily]

In article 4dbf3113.5050...@xs4all.nl,
 Irmen de Jong ir...@xs4all.nl wrote:
 I still see a problem when you are not installing by hand, but with PIP or 
 easy_install.
 When you are installing a package with a weird setup script like gevent, 
 using PIP, you
 hit a barrier. Because I cannot tweak the setup.py script that PIP will be 
 running (and
 the --install-option of PIP didn't do what the setup.py script wanted, I 
 tried it but
 the setup.py didn't like it in any shape or form)

Try setting the options in the environment variables like CFLAGS and 
LDFLAGS, as I mentioned in my previous reply.  Then you shouldn't need 
to modify setup.py so you can easy_install or pip.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Extension module compile fail, due to isysroot param pointing to sdk without certain headers. Any tips?

[Ned Deily]

In article 4dbdcff5.5050...@xs4all.nl,
 Irmen de Jong ir...@xs4all.nl wrote:
 I recently ran into a problem installing a module because it needed to 
 compile an
 extension written in C. The compilation failed because the c extension needed 
 a header
 file+lib that gcc could not find. This was caused by the fact that distutils 
 was adding
 a '-isysroot' parameter to the gcc command line that pointed to the 10.4 SDK 
 location on
 my mac. That SDK location doesn't have the particular header file. The issue 
 is almost
 identical to this old message:
 http://mail.python.org/pipermail/pythonmac-sig/2009-October/021712.html
 
 In the meantime, I worked around the problem by replacing the Python.org 
 python by a
 non-framework version that I built from source. Building the extension module 
 was fine
 because it could find the c-library dependency just fine from 
 /usr/local/include this time.
 
 This is on a mac mini powerpc, mac os 10.5.8, python.org python 2.7.1 for 
 ppc+intel.
 
 My questions are:
 It's only recently that I discovered about the -isysroot option and I'm not 
 sure how to
 deal with it. What would be the right way to solve the error I experienced?
 Can I compile+install custom c libraries in the SDK location? If so, how 
 would I do
 that? (I only seem to manage to compile+install them into /usr/local)

If the extra header files and lib files are in /usr/local, you should be 
able to include those by either modifying the setup.py file included 
with the module or, more simply, by setting the appropriate values in 
the conventional environment variables CFLAGS and LDFLAGS which 
Distutils looks at and uses.  If the module itself requires OS X 
interfaces that are not in the 10.3 ABI (most python.org Pythons are 
built with MACOSX_DEPLOYMENT_TARGET=10.3), you may be able to override 
the -sysroot value by pointing at the 10.5 SDK but I'm not sure that 
really works.  If you could supply an example and open a bug tracker 
issue, that would be good.

The relevant code for 2.7.1 is here:

http://hg.python.org/cpython/file/5395f96588d4/Lib/distutils/ccompiler.py
http://hg.python.org/cpython/file/5395f96588d4/Lib/distutils/unixccompile
r.py

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?

[Ned Deily]

In article 64461.1302209...@parc.com, Bill Janssen jans...@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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?

[Ned Deily]

In article rowen-81d53b.15565607042...@news.gmane.org,
 Russell E. Owen ro...@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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Can't import pyserial- after installing with easy_install on OSX 10.6.6

[Ned Deily]

In article 
AANLkTimnOCc35=iTbuLsSLUE+iZ3Rx=3nj7w66nj1...@mail.gmail.com,
 Tony Cappellini cappy2...@gmail.com wrote:
 I've installed pyserail via easy_install by - easy_install pyserial
 
 When I import pyserial, it cannot be found.
 
 Looking
 at 
 /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
 pyserial doesn't have a directory via the same name.
 
 There is this pyserial-2.5-py2.7.egg however.
 
 Is this typical for installing packages on OSX?
 Did the installer not complete?

That's what you would expect using easy_install.  Distributions get 
installed into either a directory like that or a zipfile version of the 
directory.

But, somewhat confusingly, it appears the module name is serial. 

http://pyserial.sourceforge.net/shortintro.html#configuring-ports-later

After installing, import serial works for me.  I don't have a serial 
port on this machine to try anything further, though.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Framework Python and X11

[Ned Deily]

In article 
AANLkTiks=y9z2omufspejwnb-araivoxg1bvvy_jz...@mail.gmail.com,
 Ben McClure mccl...@hkl.hms.harvard.edu wrote:
 The group I work with needs a Python with tkinter over X11 as well as
 wxPython.  wxPython requires a framework build of Python on Mac, and
 the current one I have is non-framework, using X11.  Is there a way of
 building a framework Python that still supports X11 tkinter?

The python.org installers for Mac OS X do not support linking to an X11 
tkinter.  The simplest solution might be to install a Python from 
MacPorts.  The current MacPorts Tk is an X11 Tk, its Pythons are 
framework builds, and it has its own wxPython ports.  (I have no 
personal experience with wxPython.)

If you install the base MacPorts, one command might install all you need:

$ sudo port py27-wxpython # or py26-wxpython or ..

http://www.macports.org/ports.php?by=namesubstr=wxpython

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app and .so files

[Ned Deily]

In article 
aanlktikwtnqn-s-r3q7fr29u0rcozeccdnef2eq-m...@mail.gmail.com,
 André Sintzoff andre.sintz...@gmail.com wrote:

 From source, using make local and make install which copies all files
 in /usr/local/lib/python2.5/site-packages/mercurial/
 
 After copying 
 dist/TortoiseHg.app/Contents/Resources/lib/python2.5/lib-dynload/mercurial/*
 in 
 /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dyn
 load/mercurial
 the application fails a little bit further with:
 ImportError: 
 '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dy
 nload/PyQt4/QtCore.so'
 not found
 
 So, the problem is perhaps not specific to mercurial itself.

You should not be copying *anything* into /System/Library/Frameworks.   
That's part of OS X and managed by Apple.   User-installed site packages 
for the system Pythons are not installed there (at least on recent 
versions of OS X), they are installed into /Library/Python.  But for 
your use case (i.e. to make a standalone distributable app), you don't 
want to have anything to do with the system Python.  I'm no longer 
familiar with that old version of Python 2.5 (BTW, there is a newer 
Python 2.5.4 OS X installer still available from python.org here: 
http://www.python.org/download/releases/2.5.4/ ), but the normal place 
for it to be looking for site-packages is:

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pack
ages

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app and .so files

[Ned Deily]

In article 
AANLkTimTQwMsKAp4kqR_By4SB4YNYX2kpHJT6XPuth=m...@mail.gmail.com,
 André Sintzoff andre.sintz...@gmail.com wrote:

 2011/3/4 Aahz a...@pythoncraft.com:
  On Fri, Mar 04, 2011, Andr? Sintzoff wrote:
 
  The application is created with:
  $ python setup.py py2app --use-pythonpath
 
  Unfortunately, when
  $ open ./dist/TortoiseHg.app/Contents/MacOS/TortoiseHg
  the following message is displayed
  ImportError: 
  '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib
  -dynload/mercurial/osutil.so'
  not found
 
  I'm wondering why the application searches modules in
  /System/Library/Frameworks/Python.framework and not in the bundle just
  created where the files are available.
 
  You need to download from python.org; using the built-in Python causes
  py2app to behave differently.
 
 I just tried to install MacPython
 (http://pythonmac.org/packages/py25-fat/dmg/python-2.5-macosx.dmg)

Is there a reason you need to use a very out-of-date Python 2.5?   More 
recent released installers are available here:

http://python.org/download/

For maximum compatibility, stick to one of the 32-bit-only 10.3+ 
installers, say, for python2.7.
 
 Unfortunately, I have some issues regarding paths...
 I got the following import error when launching my application:
 ImportError: No module named PyQt4.uic.Compiler
 
 I'm afraid to have done something modifying sys.path but I don't see what.

After installing the new Python, you'll need to install a copy of 
easy_install for it (either setuptools or Distribute) and then 
re-install any other 3rd-part packages that you need, like py2app and 
PyQt.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app with wxpython

[Ned Deily]

In article 4d624d92.5070...@etrix.com.au,
 Brendan Simon (eTRIX) brendan.si...@etrix.com.au wrote:
 I tried again with my Python 2.5.4 install and that does have the problem.
 
 pythonw myapp.py works fine.
 
 python myapp.py fails with the following error.
 
 Traceback (most recent call last):
   File myapp.py, line 18, in module
 import main as myMain
   File /Users/brendan/src/main.py, line 19, in module
 from theapp import MyApp
   File /Users/brendan/src/theapp.py, line 20, in module
 import wxAnyThread
 ImportError: No module named wxAnyThread
 
 It looks like it is just a path issue.  So it should be easy to solve,
 but there is a difference in behaviour between python and pythonw with
 Python 2.5.4, even though the binaries are identical.  I presume that
 the the interpreter looks at the command that it is invoked with and
 does something different with sys.path ??

That still seems suspicious. If you are using Python 2.5.4 from the 
python.org installer, it also installs identical bin/python2.5 and 
bin/pythonw2.5 binaries, with bin/python and bin/pythonw as symlinks to 
the versioned names.  So all four names *should* behave identically, 
assuming all the names are being picked up from the framework bin 
directory, /Library/Frameworks/Python.frameworks/Versions/2.5/bin.  Make 
sure you are really using them:

  which pythonw
  which python

If necessary, you may need to specify absolute paths to the bin 
directory or temporarily change your shell PATH to ensure the 2.5 bin 
directory comes first (note, that Apple ships its own version of Python 
2.5, linked in /usr/bin, in both OS X 10.5 and 10.6).

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] The time module

[Ned Deily]

In article c937b19b-9fed-415f-85b1-4c2c86e15...@gmail.com,
 Rafael Bejarano beja...@gmail.com wrote:
 I can't get the clock() function in the time module to work. I would  
 appreciate any helpful suggestions.
 
 Below is a copy of the Terminal session, for your perusal.
 
 Thanks.
 Rafael Bejarano
 
 Last login: Mon Feb 21 13:02:48 on ttyp1
 Welcome to Darwin!
 173-216-77-254-arka:~ Rafael$ python
 Python 3.0.1 (r301:69597, Feb 14 2009, 19:03:52)
 [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
 Type help, copyright, credits or license for more information.
   import time
   clock()
 Traceback (most recent call last):
File stdin, line 1, in module
 NameError: name 'clock' is not defined
  

Importing a module creates a new namespace for the names in that module.:

$ python3.2
Python 3.2 (r32:88452, Feb 20 2011, 11:12:31) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type help, copyright, credits or license for more information.
 import time
 time.clock()
0.091744

You might want to review the Python tutorial here:
http://docs.python.org/py3k/tutorial/index.html

And, by the way, you should upgrade to Python 3.2 as soon as possible.  
Python 3.0.1 was a very early release of Python 3.  It is known to be 
buggy and is no longer supported.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app with wxpython

[Ned Deily]

In article 4d61918e.1010...@etrix.com.au,
 Brendan Simon (eTRIX) brendan.si...@etrix.com.au wrote:
 Do you need to specify 'pythonw' as the interpreter ??
 It may depend on python version.  I found (on OS X) that Python 2.7 
 requires pythonw rather than python to run my wxPython apps.

That sounds very suspicious.  On OS X installs, bin/python and 
bin/pythonw are supposed to be identical.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [ann] py-appscript 1.0.0 final release

[Ned Deily]

In article aa6a1c14-40fd-41c2-976b-bb02340af...@gmail.com,
 Andre Renault kestrel.an...@gmail.com wrote:
 On 2011-02-06, at 1:56 PM, has hengist.p...@virgin.net wrote:
Just to let you know that Python appscript 1.0.0 has
finally been released: 
   http://pypi.python.org/pypi/appscript
 Hooray!

+1.0.0 !

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] IDLE not working

[Ned Deily]

In article blu0-smtp202ce31c5860bb7639db113fa...@phx.gbl,
 Catena Duscio catena.dus...@hotmail.com wrote:
 I have downloaded python 3.1 many times in the last coupe of days and each 
 time I can not get the IDLE to open. 

If you have downloaded Python 3.1.3 from the python.org website, try 
launching IDLE from a terminal shell window instead of double-clicking.  
In the shell, type:

/Library/Frameworks/Python.framework/Versions/3.1/bin/idle3.1

If it fails, there should be a traceback printed which may give a clue 
as to the problem.  If it does not, then quit IDLE and launch by 
double-clicking on IDLE.app in the Finder.  You will then need to look 
in the system.log to see any error messages if IDLE fails to launch.  
The Console.app in /Applications/Utilities makes that easy to do.

One recently reported problem with IDLE 3.x is that it can crash if its 
Recent Files list contains files with non-ascii characters in their path 
names.  That can happen if you were using IDLE 2.x with such files, 
where this is no problem.  A workaround is to simply delete the recent 
file list before launching IDLE 3.x:

  rm ~/.idlerc/recent-files.lst

The problem and a fix for it is here:

http://bugs.python.org/issue10974

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] How to get a Mac OS X version of Tcl/Tk rather than X11 version.

[Ned Deily]

In article 960836.10021...@web34405.mail.mud.yahoo.com,
 Lou Pecora lou_boog2...@yahoo.com wrote:

 I have an installation of Python 2.6.4 on my MacBook Pro (OS X 10.6) that by 
 default uses X11 windows and dialogs rather than the Mac version of those GUI 
 items.  In my googling and exchanges on other support groups I've come down 
 to 
 the problem may be with the Tcl/Tk installation using the generic X11 GUI 
 rather than the Mac version.  Does anyone know how I can change that in the 
 Tk 
 part of the python framework?

Which Tcl/Tk is used by Python depends on the way the Python you are 
using was built.  The Apple-supplied Pythons in OS X and the Pythons 
installed from python.org and some 3rd-party suppliers (like ActiveState 
Python) use the native Aqua Tk, the most common versions being those 
shipped by Apple with OS X or the ActiveState Tcl/Tk distribution of OS 
X.  Python 2.6.4 is not the version shipped by Apple in 10.6 so you must 
have built or installed another version. `which python` will tell you 
where it is installed.   If the path starts with /opt/local/ chances 
are you using a MacPorts Python; currently the MacPorts Python uses a 
MacPorts Tk port which by default is built with X11, rather than as a 
Aqua Tk.  The MacPorts Tk port does have a +quartz variant which is 
supposed to build Aqua Tk but it currently does not work on 10.6.

To get back to using an Aqua Tk, you can install the most recent 2.6 
Python (2.6.6) from python.org:

http://www.python.org/download/releases/2.6.6/

It uses Aqua Tk 8.4 and is 32-bit only.  Note that 2.7.1 and 3.1.3 (soon 
to be 3.2) are the current versions of Python.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python development on OSX

[Ned Deily]

In article 
aanlktimaqylndoskyvo5fnpfui4lwd61697nauutw...@mail.gmail.com,
 Tony Cappellini cappy2...@gmail.com wrote:
 On Sun, Jan 16, 2011 at 7:30 PM, Daniel O'Donovan 
 dan.odono...@gmail.comwrote:
  I think you'll find that the biggest difference between MacPorts python
  (and fink python) and most other builds (python.org for example), is that
  MacPorts uses X11 rather than Aqua (Apple's native window manager) and are
  not built as Apple 'Frameworks' - but rather regular shared libraries (more
  like with linux).

Actually, while Fink uses a Unix-style shared library build, most other 
distributors including MacPorts, the Apple-supplied Pythons in OS X, and 
the ActiveState Pythons, use an OS X framework build based on the 
python.org builds.  The Tk on MacPorts is built as an X11 version by 
default but there is an Aqua port variant at well.  Unfortunately, the 
Aqua variant is broken on OS X 10.6 but there is hope that it will get 
unbroken now that ActiveState has started packaging a reliable version 
of the patched Cocoa-based Tk 8.5 which works in both 32- and 64-bit 
modes.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python development on OSX

[Ned Deily]

 
manager, like MacPorts or Fink, will eliminate the guess work and 
automatically build and install all the required dependencies in a 
compatible way so that it should all just work.  That's probably the 
biggest reason for the popularity of installing Python from one of those 
distributors: it can be a huge time saver.

On the other hand, it is very difficult for volunteer-staffed projects, 
like most of these are, to keep on top of every package and keep them 
all up-to-date with optimal configuration selections.  That's one of the 
reasons for commercial distributions, like ActiveState Python and the 
Enthought Python distribution, both of which build off of python.org 
configurations but add their own packages and offer paid support options 
on top of things.  They also may target specific communities: EPD caters 
to the scientific / numeric user community.

Another complicating factor has been the way third-party Python packages 
have been made available.  Over the past ten years are so, there have 
been a number of key improvements and growing standardization in Python 
packaging, first with Distutils and then later easy_install (setuptools) 
and now Distribute, Pip, and buildout to name a few.  Not so long ago, 
it was much more difficult for users to install more complex packages 
especially those with C extension modules and so some projects 
distributed their own binary installers for various platforms including 
dependent libraries, like you've seen with wxPython.  These days it is a 
lot easier to automatically build and install Python packages, however 
the problems associated with dependent libraries often remain (which is 
a strength of the MacPorts or Fink comprehensive solution approach).

So, all in all, there are lots of reasons plus others I'm forgetting.  
Many of them are not unique to the Mac world.  But that doesn't make 
things less daunting when you first dive in.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Escaping commandline strings

[Ned Deily]

In article 
aanlktik8e7h8-tqw2=f5f30uke_d99yytu=0dvylk...@mail.gmail.com,
 Chris Weisiger cweisi...@msg.ucsf.edu wrote:
 I want to sanitize some strings (e.g. escape apostrophes, spaces, etc.)
 before passing them to the commandline via subprocess. Unfortunately I can't
 seem to find any built-in function to do this. Am I really going to have to
 write up my own sanitizer? Not that it'd be much effort, but I'd much rather
 use an official function than risk forgetting something.

The subprocess doc show how to use shlex to parse a shell-like command 
string.  I'm not sure I understand your use case but is there a reason 
you can't use 'shell=False' and set up the arguments yourself, thus 
avoiding the need for escapes?  Even if you really need to have a shell 
execute the string, you should be able to set up the arguments and call 
the shell directly.  

http://docs.python.org/library/subprocess.html

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] python3.2 osx build

[Ned Deily]

In article 4d225d98.8020...@gmail.com,
 Stephen Gava elgua...@gmail.com wrote:
 i'm guessing that since there was never a 3.2 beta 2 build for osx 
 released, and since it's the holiday season, and since 3.2 rc1 is due in 
 just 4 days now, that beta 1 has been / will be simply skipped for osx...?

Yes, unfortunately, 3.2b2 has not appeared yet.  FWIW, the beta 1 
installer is still available here:

http://www.python.org/ftp/python/3.2/python-3.2b1-macosx10.3.dmg
 
 anyone know? or know if there will even be an rc1 build for osx released?

I'm sure there will be an rc1 installer.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Accessing the iTunes database directly?

[Ned Deily]

In article 21b38dbc-8071-6179-89c7-b9cbb050a...@me.com,
 David Stokes sto...@mac.com wrote:
 Can the iTunes library database be accessed directly via Python? What I want 
 to do are some fairly basic manipulations of the data but using the scripting 
 API (from both appscript and AppleScript) was ridiculously slow; operations 
 that took seconds in comparable manipulations of a SQLite database of a 
 similar size took multiple hours. I had thought I'd heard that iTunes uses -- 
 or once used -- SQLite, but either it has changed or I was just looking in 
 the wrong place.

 If nothing else, I suppose I can use an XML export of the 
 library data and then re-import it.

Keep in mind that, depending on how your iTunes library is configured, 
changes to a track's metadata may cause iTunes to update the metadata in 
the music file (mp3 tags, etc), which may take a long time to rewrite 
each affected music file.  That can make mass updates *very* slow 
regardless of how you do it: manually or through a scripting interface.  
You can parse the iTunes XML file easily in Python but, AFAIK, the only 
ways to then update the iTunes data are by either reimporting the 
modified XML library file, which might cause you to lose some 
information, or through the scripting API; I don't know of any public 
APIs to iTunes internal DBs.  If you don't care about the tags in the 
music files themselves, you may be able to inhibit the file updates by 
experimenting with some of the iTunes preferences or possibly by 
temporarily changing the music files' permissions.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] utf-8 using python 2.6.1 (os x 10.6.4)

[Ned Deily]

In article p06020402c92c14625...@[192.168.1.13],
 Jym Feat j...@ai.univ-paris8.fr wrote:

 I'm having issues when using python 2.6.1 in interactive mode : it wouldn't 
 let me type anything but plain ascii... while the terminal itself will 
 properly display french accented characters as entered on the fly;
 
 so I looked into site.py, found that silly instruction was still there on 
 line 456, changed it, to utf-8, but still no go...
 
 hunting for a solution on the web, I learned about PYTHONIOENCODING and set 
 it to utf-8 in my environment: still no accented french chars...
 
 then I checked the 'escape non ascii' option in the terminal settings: now I 
 can type words like Noël or Pâques, but there are still some oddities, like 
 the ¦ ligature for instance, that display as ?^?^?
 
 has anybody solved that issue?

Without looking at it more closely, my guess would be an issue (or 
difference) between the Apple-supplied editline library which Apple uses 
as a substitute for the GNU readline library in the system-supplied 
Python 2.6.1 in OS X 10.6.  If you have the time, please try using the 
python.org 32-bit-only python 2.7.1 installer which is linked with GNU 
readline and then the python.org 64-bit python 2.7.1 which is currently 
linked with editline.  If the problem is duplicated there, please open 
an issue on the python bug tracker (bugs.python.org).

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] 2.7.1 build?

[Ned Deily]

BTW, the official 2.7.1 OS X installers are now available:

http://www.python.org/download/releases/2.7.1/

With Python 2.7, there are two Mac OS X installer variants available for 
download: the traditional 32-bit-only (Intel and PPC) version that 
installs and runs on all versions of OS X from 10.3.9 through current 
10.6.x; and a new 64-bit/32-bit (Intel only) variant.  As discussed in 
http://bugs.python.org/issue9227, there were problems using Tkinter and 
IDLE with the original 2.7 64/32 installer.  The problem is that the 
only supported non-X11 64-bit Tcl/Tk at the moment is the one supplied 
by Apple in 10.6 and the installer tried unsuccessfully to support both 
10.5 and 10.6.  For 2.7.1, the 64/32 installer now only supports 10.6.x 
and will only use the Apple-supplied Tcl/Tk 8.5.  The 32-bit-only 
installer is still built to link with either an Active/State Tcl/Tk 8.4, 
if installed in /Library/Frameworks, or fallback to the Apple-supplied 
Tcl/Tk 8.4 in OS X 10.4 through 10.6.

The official 3.1.3 installer is also now available:

http://www.python.org/download/releases/3.1.3/

As with previous 3.1.x installers, it is a traditional 32-bit-only 
installer (Intel/PPC, 10.3.9 - 10.6, Tcl/Tk 8.4, etc).

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] How to add appscript module to a pyobjc project?

[Ned Deily]

In article 
aanlkti=uzk73=srvau9bf-na9q+n1lzeqf7-ygzqj...@mail.gmail.com,
 Fur Yao i...@yaofur.com wrote:
 In my app , I want to use appscript .
 
 I use easy_install appscript , and it works well in my python script.
 
 But when I build a Mac app in xcode , an error appears.
 
 
from appscript import app , k
 ImportError: No module named appscript
 
 
 Then I copy the appscript folder direct from
 /Library/Python/2.6/site-packages/appscript-0.21.1-py2.6-macosx-10.6-universa
 l/
 to
 the app's Resources folder.
 and I also copy aem mactypes.py osax.py
 
 And it appears:
 
 ImportError: Bad magic number in
 /Users/Kebot/git/Giraffa/build/Debug/Giraffa.app/Contents/Resources/appscript/
 __init__.pyc

Your Xcode project is apparently using a different version of Python 
than the one appscript was installed with.  If you are on OS X 10.6, you 
may have the Xcode target set for 10.5 instead of 10.6 and, thus, are 
using the Apple-supplied python2.5 in your project.

For example:

$ /usr/bin/python2.6 
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ma
cpath.pyc
$ /usr/bin/python2.5 
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/ma
cpath.pyc
RuntimeError: Bad magic number in .pyc file

If you do need to support 10.5, try installing appscript with python2.5, 
too.

$ /usr/bin/easy_install-2.5 appscript

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Select application version

[Ned Deily]

In article 20101108123526.ga29...@pinux.info,
 Carles Pina i Estany car...@pina.cat wrote:
 I'm not an advanced Applescript user, but I usually have a problem: how can I
 choose the application version that I want my script to connect to?
 
 Let's say that I have Microsoft Office 2004, 2008 and 2011. How can I select
 the version in the tell statement?
 
 The final use case is using Python, I thought that appscript.app() could have
 some argument to specify it, but it seems that it doesn't have any. I also
 tried appscript.app(Disk:Applications:Microsoft Office 2011:Microsoft Word)
 without any luck (Local applicatoin Disk:Applications:... not found)

Use a POSIX path to the application:

app(/Applications/Microsoft Office 2011/Microsoft Word.app)

http://appscript.sourceforge.net/py-appscript/doc/appscript-manual/07_app
licationobjects.html

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] os.getcwd() returns lower case current working directory

[Ned Deily]

In article 98b8e796-eeb7-4c19-92b9-200bfed9a...@gmail.com,
 Klaasmer klaas...@gmail.com wrote:
 when I call os.getcwd() on my Mac under OS X 10.6.4 from my home directory, 
 the path is converted to lowercase. I get
 
 /users/myusername
 
 instead of
 
 /Users/myusername
 
 On another Mac I get the correct uppercase string. How can I configure this? 
 Is there a (hidden) Python setting?
 
 Reason for asking: On OS X all user directories are in /Users. This is 
 always uppercase. When using Mercurial, it gets sometimes confused with this 
 strange and incorrect normalization of my current directory.

[Note to readers here:  the OP asked this question also on Stack 
Overflow and has subsequently found that the same behavior is exhibited 
by an ObjC program.  So it turns out to not be a Python issue at all.]

http://stackoverflow.com/questions/4073469/how-can-i-get-the-correct-case
-when-calling-pythons-os-getcwd

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] MySQLdb on OS X 10.6

[Ned Deily]

In article 30087228.p...@talk.nabble.com,
 brinsknaps brian.ngu...@gmail.com wrote:
 I really appreciate the reply! I finally made some progress after daunting
 attempts to get msyql up and running from macports. Ultimately it had to do
 with some permission issues. 
 
 Anyway, I can feel a tad bit closer, but am still running into a roadblock:
 
 $~/ python
 Python 2.6.6 (r266:84292, Oct 27 2010, 13:07:13) 
 [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
 Type help, copyright, credits or license for more information.
  import MySQLdb
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site
 -packages/MySQLdb/__init__.py:34:
 DeprecationWarning: the sets module is deprecated
   from sets import ImmutableSet

Fortunately, that warning can be ignored; it should have no impact on 
anything.  It is an indication, however, that the MySQLdb version in 
MacPorts has not been updated yet from 1.2.2 to 1.2.3, which was 
released earlier this year and, among other changes, removes the source 
of that warning.  Unless you find some other reason that you need to 
update to 1.2.3, I'd advise just living with the warning until the 
MacPorts port is updated and you feel like updating everything:

  $ sudo port selfupdate
  $ sudo port upgrade outdated
 
 Moreover, once I try the syncdb command in django, I get:
 
 $~/Sandbox/mysite/ ./manage.py syncdb
[...]
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/sit
 e-packages/MySQLdb/connections.py,
 line 170, in __init__
 super(Connection, self).__init__(*args, **kwargs2)
 _mysql_exceptions.OperationalError: (1045, Access denied for user
 'admin'@'localhost' (using password: YES))

Most likely you don't have the correct values in your Django project's 
settings.py file for one or more of the DATABASE_ variables.  First, 
make sure your MySQL server is up and running and that you can connect 
to it using one of the standard MySQL command line programs like 
mysqladmin5 using a valid MySQL user name and password.  Then edit 
settings.py appropriately.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] MySQLdb on OS X 10.6

[Ned Deily]

In article 30054281.p...@talk.nabble.com,
 brinsknaps brian.ngu...@gmail.com wrote:
 I know it's been a long time since you posted this message, but I've been
 pulling out my hair running into the same issue. I've tried installing
 32-bit and 64-bit versions of mysql to test different compatibilities with
 python 2.6.6, but have had no luck. By any chance did you figure out a
 solution to this problem?

The key to successfully installing MySQLdb on 10.6 is to ensure that the 
Python version, MySQLdb, and the MySQL client libraries are all built 
with a common architecture (i386 or x86_64) and ABI (deployment target).  
Unfortunately, that's easier said than done if you try to do it yourself 
from source or with installers from various sources.  It can be done but 
my advice is to install everything from MacPorts 
(http://www.macports.org/).  If you haven't already, download and run 
the base MacPorts installer.   Then you can build and install everything 
you need with:

$ sudo /opt/local/bin/port selfupdate
$ sudo /opt/local/bin/port install py26-mysql

py26-mysql is the MacPorts port name for MySqLdb and installing it will 
automatically also build all necessary dependencies like Python 2.6 and 
the MySQL client libraries and they will be built compatibly.  To prefer 
the MacPorts python2.6, add its framework bin directory to the front of 
your shell search PATH, so something like;

$ export 
PATH=/opt/local/Library/Frameworks/Python.framework/Versions/Current/bin:
/opt/local/bin:$PATH

You'll find more suggestions and details by searching on StackOverflow.

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] pyobjc with appscript

[Ned Deily]

In article 
aanlkti=ngrh9vi1ttynlmnqicttjswmm+7crdzxbw...@mail.gmail.com,
 Adam Morris amor...@mistermorris.com wrote:
 I have a python script that gives Keynote some added features useful to
 teachers. It lets students interact with whatever is being projected right
 at their desk. It's written in python using appscript but at the moment runs
 entirely from the command line.
 
 I'm looking at giving it a GUI. I'm considering using the AppleScriptObjC
 bridge, but that means converting all my convenience classes from
 python/appscript into pure AppleScript (boo). The upside though is that I
 could get started on that right away.
 
 I'd really rather use PyObjC but would need a helping hand getting started
 on making a deployable Snow Leopard-only app, and getting it so that
 appscript is included. How do I do that without requiring the user to have
 appscript in its python path? This isn't the first time I've tried figuring
 this out and don't understand how this works. Can someone point me in the
 right direction?

Another suggestion is to look at using Greg Ewing's PyGUI project, an 
attempt at a modern cross-platform GUI API for Python.  It uses PyObjC 
on OS X.

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

-- 
 Ned Deily,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG