matplotlib-devel Mailing List for matplotlib

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

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