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

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.

(On 2.7, I think this would also make wxpython applications work, but I
haven't checked recently.)

yup -- it should -- does for me anyway.

If there is some reason why this default to a framework is not a good idea,

and/or cannot be implemented very soon in Anaconda, then I think we need to
immediately remove macosx as a default in matplotlib. A situation where a
new Anaconda user fires up ipython and tries to plot, and it fails, is
intolerable.

for what it's worth, I get odd os-x errors trying to se default MPL with
Anaconda as well -- haven't tried pythonw for that yet. (kludged it by
using the Agg back end only)

···

On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efiring.ocean@...149...> wrote:

--

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

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

···

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.

[I'm switching the subject because my comments below relate to ipython and matplotlib, and are no longer Anaconda-specific.]

Derek,

Thanks. A few days ago, when I switched from testing on linux to testing on osx, exactly this ipython slowdown was happening to me--but I lost track of what combination of versions and invocations was causing it. Therefore I have been concentrating on the severe problem which was, for me, 100% repeatable, and involved macosx backend, not Qt. I expect the macosx-relatec problem will go away after Ilan uploads the revised Anaconda ipython for python 3.

Now I find I can repeat the ipython problem on Homebrew python 3 (framework--with Quartz app) and Anaconda with the un-fixed ipython (which is running without starting a Quartz app):

ipython --pylab=qt

Leave it alone for a bit. Try scrolling through history. Long delay, even in responding to Ctrl-C. Evidently key events are stacking up and not being processed. Now try:

ipython
%pylab qt

I see the slowdown with this, also. The response delay seems to get worse with time. It renders the session unusable after only a few minutes.

ipython
%gui qt

And I still see it, so this appears to be a problem in ipython's PyQt4 gui handling, not directly related to matplotlib. All on Mavericks, running ipython from Apple's terminal.

Eric

···

On 2014/08/15, 9:37 AM, Derek Homeier wrote:

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.