I'm no bash scripting expert, but I think the problem here is that the
Anaconda pythonw script does not quote "$@". That is, I suspect that the
third line of the script should be:
/Users/Harold/anaconda/python.app/Contents/MacOS/python "$@"
rather than:
/Users/Harold/anaconda/python.app/Contents/MacOS/python $@
The latter causes command line arguments that contain spaces to be split
and passed on as multiple arguments, while the former avoids the splitting.
So, for example, if I create a file called "test.py" containing
import sys
print sys.argv
and run
pythonw test.py "1 2" 3
(where pythonw invokes the regular Anaconda pythonw) the output is
['test.py', '1', '2', '3']
but with the "$@" quoted I get:
['test.py', '1 2', '3']
I discovered this apparent fix by reading the "Positional Parameters"
section at http://www.tldp.org/LDP/abs/html/internalvariables.html#APPREF .
Harold Mills
On Thursday, August 21, 2014 7:40:04 PM UTC-4, Chris Beaumont wrote:
>
> 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 <chris....@noaa.gov
> <javascript:>> wrote:
>
>> On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aaron....@continuum.io
>> <javascript:>> 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...@astro.physik.uni-goettingen.de <javascript:>> wrote:
>>> > On 14 Aug 2014, at 11:40 pm, Chris Barker <chris....@noaa.gov
>>> <javascript:>> wrote:
>>> >
>>> >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efirin...@gmail.com
>>> <javascript:>> 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 anaconda+u...@continuum.io <javascript:>.
>>> > To post to this group, send email to anac...@continuum.io
>>> <javascript:>.
>>> > 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
>>
>> chris....@noaa.gov <javascript:>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> matplotl...@lists.sourceforge.net <javascript:>
>> 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
> *************************************
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
