The only potential issue I can think of for making python=pythonw is
that pythonw is a shell script:
I agree -- that could create issues (though will mostly work, I suppose)
But somehow the python.org build has managed to make a pythonw that IS a
proper executable:
ORRW-M-1275474:bin chris.barker$ pwd
/Library/Frameworks/Python.framework/Versions/2.7/bin
ORRW-M-1275474:bin chris.barker$ ls -l pythonw
lrwxr-xr-x 1 root wheel 8 Jul 16 2013 pythonw -> pythonw2
ORRW-M-1275474:bin chris.barker$ ls -l pythonw2
lrwxr-xr-x 1 root wheel 10 Jul 16 2013 pythonw2 -> pythonw2.7
ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7
-rwxr-xr-x 1 chris.barker admin 9180 May 13 2013 pythonw2.7
ORRW-M-1275474:bin chris.barker$ file pythonw2.7
pythonw2.7: Mach-O executable i386
(yes, ti works for 64 bit too -- this just happens to be what I have)
It would be nice if Anaconda would do it the same way.
-Chris
···
On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aaron.meurer@...1211...> wrote:
#!/bin/bash
export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python
/Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@This is needed because otherwise Python thinks its sys.prefix is
../../ from the executable, i.e.,
/Users/aaronmeurer/anaconda/python.app/Contents/MacOS$~/anaconda/python.app/Contents/MacOS/python
Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/Users/aaronmeurer/anaconda/python.app/Contents'I'm not sure what kinds of issues this would cause having python be a
shell script rather than a Mach-O 64-bit x86_64 executable (or a
symlink to a Mach-O 64-bit x86_64 executable).I suppose you could do this (replace 3.4 with 2.7 if you use Python 2):
$mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig
$ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4and see if anything breaks (or if you don't want to risk breaking your
main Python install, do it in a separate conda environment).Aaron Meurer
On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier > <derek@...873...> wrote:
> On 14 Aug 2014, at 11:40 pm, Chris Barker <chris.barker@...236...> wrote:
>
>> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efiring.ocean@...149...> > wrote:
>> but as far as I can see, on OSX, there is no *advantage* to
non-framework python. Is this correct?
>>
>> Suggestion for anaconda:
>> make bin/python a link to ../python.app/Contents/MacOS/python
>>
>> NOTE: the python.org python build has been doing this (or something
like it) for years and many versions -- I had gotten pretty used to it and
was pretty annoyed when I discovered Anaconda keeps anon-framework binary
as the default.
>>
>> It was annoying enough that I had to explicitly call pythonw (or alter
the #! line) for my wxPython scripts, but with ipython it's even worse --
how would I start up ipython with a framework build?
>>
>> NOTE: if the Anaconda folks really think there is a real downside to
using the framework executable for the default python, maybe the ipython
start up script could use pythonw ?
>>
>> Eric - have you tried recent MPL with the python.org builds to confirm
the issue? I'm a bit surprised that it would even semi-work -- when I try
wxPython with the regular executable, I get an error message and it wont
run at all.
>>
> Just to make sure I understand - this is about whether the MPL macosx
backend would run with non-framework
> Python at all? It certainly should not, as _macosx.m has been enforcing
an error in this case for some versions.
> That put aside, when I disable the error at the end of _macosx.m I found
the OSX backend to still work as it used
> to under OS X 10.9 with the Fink Python installation (which is not built
as a framework, and unfortunately unlikely
> to change in foreseeable time). I.e. the only obvious problem is the
lack of control by the window manager.
> Overall I still find it to perform better than any of the alternative
backends. But having switched to PyQT4 as the
> default backend due to the above Fink troubles, I did notice some
oddities under Mavericks. I have no idea if they
> are related to the problems Eric had originally reported, but they are
clearly Mavericks-specific:
>
> When using MPL with ipython --pylab and the Quartz version of PyQT4, the
interpreter seems to be slow down
> extremely after running for a little while. Weirdly this is not
connected to any graphics display and in fact happens
> even without any plotting window opened, i.e. the ipython shell just
randomly becomes completely unresponsive
> and hangs for several seconds on simple tasks like typing or navigating
through history. The plotting itself actually
> does not appear to perform any worse than it used to under Mountain Lion.
> None of this seems to occur with the X11 variant of PyQT4.
> When launching ipython without the --pylab flag and loading MPL later
(e.g. with 'import matplotlib' in the ipython
> profile), none of these stalls or hangups occur, but plots sometimes
seem not to refresh properly even with a
> plt.draw() and one has to manually resize the plot window to force
redrawing of the figure.
> This might be primarily a PyQT4 or Ipython issue, but obviously it is
somehow connected to the pylab mode of Ipython.
>
> Cheers,
> Derek
>
> --
> Anaconda Community Support Group Brought to you by Continuum Analytics
> ---
> You received this message because you are subscribed to the Google
Groups "Anaconda - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send
an email to anaconda+unsubscribe@...1212...
> To post to this group, send email to anaconda@...1212...
> Visit this group at
http://groups.google.com/a/continuum.io/group/anaconda/.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...