[Anaconda Support] OSX: why not make "python" invoke the framework?

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.4

and 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...

There are some idiosyncrasies to Anaconda's pythonw -- for example, the
behavior of "-c":

python -c "print 1+2" -> 3
pythonw -c "print 1+2" -> Nothing
/usr/bin/pythonw -c "print 1+2" -> 3

chris

···

On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker <chris.barker@...236...> wrote:

On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aaron.meurer@...1211...> > wrote:

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

#!/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.4

and 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...

------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
*************************************
Chris Beaumont
Senior Software Engineer
Harvard Center for Astrophysics
60 Garden Street, MS 42
Cambridge, MA 02138
chrisbeaumont.org
*************************************

I’m no bash scripting expert, but I think the problem here is that the Anaconda pythonw script does not quote “$@”. That is, I suspect that the third line of the script should be:

/Users/Harold/anaconda/python.app/Contents/MacOS/python “$@”

rather than:

/Users/Harold/anaconda/python.app/Contents/MacOS/python $@

The latter causes command line arguments that contain spaces to be split and passed on as multiple arguments, while the former avoids the splitting. So, for example, if I create a file called “test.py” containing

import sys

print sys.argv

and run

pythonw test.py “1 2” 3

(where pythonw invokes the regular Anaconda pythonw) the output is

[‘test.py’, ‘1’, ‘2’, ‘3’]

but with the “$@” quoted I get:

[‘test.py’, ‘1 2’, ‘3’]

I discovered this apparent fix by reading the “Positional Parameters” section at http://www.tldp.org/LDP/abs/html/internalvariables.html#APPREF .

Harold Mills

···

On Thursday, August 21, 2014 7:40:04 PM UTC-4, Chris Beaumont wrote:

There are some idiosyncrasies to Anaconda’s pythonw – for example, the behavior of “-c”:

python -c “print 1+2” → 3

pythonw -c “print 1+2” → Nothing

/usr/bin/pythonw -c “print 1+2” → 3

chris

On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker <chris…@…236…> wrote:

On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aaron…@…1211…> wrote:

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 Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier > > > > > > <de…@…1214…goettingen.de> wrote:

On 14 Aug 2014, at 11:40 pm, Chris Barker <chris…@…236…> wrote:

On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efirin…@…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:

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.

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+u...@continuum.io.

To post to this group, send email to anac…@…1211…

Visit this group at http://groups.google.com/a/continuum.io/group/anaconda/.

#!/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.4

and 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> When using MPL with ipython --pylab and the Quartz version of PyQT4, the interpreter seems to be slow down> When launching ipython without the --pylab flag and loading MPL later (e.g. with ‘import matplotlib’ in the ipython

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…@…236…


Slashdot TV.

Video for Nerds. Stuff that matters.

http://tv.slashdot.org/


Matplotlib-devel mailing list

Matplotl…@…1041…sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Harvard Center for Astrophysics

60 Garden Street, MS 42

Cambridge, MA 02138

chrisbeaumont.org



Chris Beaumont
Senior Software Engineer