From: Chris B. <chr...@no...> - 2014-08-21 23:00:18
|
On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aar...@co...> 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 > <de...@as...> wrote: > > On 14 Aug 2014, at 11:40 pm, Chris Barker <chr...@no...> wrote: > > > >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efi...@gm...> > 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 ana...@co.... > > To post to this group, send email to ana...@co.... > > 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 Chr...@no... |