Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer 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 > wrote: > > On 14 Aug 2014, at 11:40 pm, Chris Barker wrote: > > > >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing > 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
Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
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 wrote: > On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer > 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 >> wrote: >> > On 14 Aug 2014, at 11:40 pm, Chris Barker >> wrote: >> > >> >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing >> 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 >
