Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?

[Chris B. <bea...@ha...>]

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 <chr...@no...> wrote:

> 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...
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


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