A while ago I switched from Enthought's old EPD to their newer Canopy system. For the most part it's nice, but one aspect has been particularly vexing.
Whenever I run a python script, either from within the Canopy iPython environment or from the command line, none of my print statements actually get printed right away when that part of the script is hit. Instead, multiple prints seem to get executed all at once at a later time.
As an example...
import numpy as np
print "About to start long computation..."
a = np.random.randn(1e8)
print "Computation finished."
doesn't print the first statement until after a is finished being generated, when both statements are printed simultaneously. (You can tell when the calculation is occurring by watching the CPU monitor.)
Does anyone know what's going on here? If relevant, I'm running Canopy 1.0.0.1160, with Python 2.7.3 64bit on a Windows 7 machine.
This looks like buffered output. Try running your script as:
python -u yourscript
The -u flag turns buffering off.
(Replace python by your OS's python executable's name.)
No, this is not a change between EPD and Canopy. While I suppose there might be some python distributions which default to buffering off, EPD was not one of them -- the performance hit could have been too severe (as kindall's comment mentions.) Better to let the programmer decide when it's important for the user to see console output immediately (typically for status updates).
BTW, IPython in the Canopy GUI is simply IPython QtConsole. If you are depending on console I/O, you may also need to be aware of this longstanding issue with QtConsole:
I don't think there's a reasonable workaround for Canopy IPython, other than do it "properly", i.e. with flush.
https://support.enthought.com/entries/22157050-Canopy-Python-prompt-QtConsole-Can-t-run-interactive-OS-shell-commands
Related
I spend a lot of time running programs from python using the subprocess module. One of my scripts uses the check_call command to run a program from the command line around 600 times. Today I updated to Spyder 3 and when I run this script I get a pop up which looks like this
This stays for the duration of the program (a few seconds) then disappears but then another appears to replace it as my programs uses the check_call command again. This behavior is very disruptive as it means I can't just run a long program in the background on my machine whilst working on something else. Also this was never a problem on the old version of Spyder I had. Does anybody know how to turn this very annoying behavior off?
(Spyder dev here) If I'm not mistaken, now you need to pass the parameter shell=True to all subprocess commands you're using to avoid this problem.
I am working on a good Python environment for use on a Windows 7 machine. I am a big emacs fan, and like using the windows native build that's part of cygwin (emacs-w32). This way, I have access to all the cygwin tools from within emacs.
I also really like Anaconda's python distribution. I really don't feature downloading and maintaining all those packages myself, esp. within cygwin.
Also a big ipython fan.
On a Linux cluster, I'm having good luck using ipython as my python interpeter within emacs. I make a lot of plots, so matplotlib has to work too.
So I'm trying to get "ipython interpeter within cygwin emacs" to work.
Is this a good idea? Better ways to go? I know there's Spyder, but I honestly like working within emacs for editing .py files. Not just emacs keybindings - the whole emacs environment (grep, ediff, dired, etc etc).
Right now, I've gotten emacs to pick up ipython in the python 3 anaconda install. It runs, but I get extransous characters, e.g.:
^A^BIn [^A^B1^A^B]: ^A^B
instead of In [ 1 ]:
Also figure windows tend to not work (figure appears, but Windows says Not Responding, plots don't appear).
Thanks.
Update:
Thanks for the response. I did some more playing. To be exact:
* Setup bash path so Anaconda python and ipython found
* Started ConEmu (windows terminal program)
* ran bash from a cmd (dos) prompt
* ran cygwin's emacs: emacs -nw -Q (no window and no customization)
* Open .py file, C-c C-z, runs Anaconda python -i
* Get these messages:
Make dedicated process? (y or n) n
Making python-shell-interpreter local to Python while let-bound!
Making python-shell-interpreter-args local to Python while let-bound!
funcall: Args out of range: "^M", 0, 2
The final line appears in the emacs "status line" at the bottom. There is a buffer with Python running, seems to be fine. Except Ctrl-D doesn't work. If I type 'quit', I get the message "Use quit() or Ctrl-Z plus Return to exit." What happened to Ctrl-D?
If I repeat the exercise with ipython, the same messages are given, ipython buffer runs, I get the random ^A^B's, Ctrl-D doesn't work.
I use Spyder 2.3.5.2 on an Anaconda Python installation running on Windows 7 64 bit.
The debug functionalities are very temperamental and unreliable. My breakpoints are often completely ignored. Sometimes applying the IT approach (closing and restarting the program) solves the issue, but more often than not it doesn't.
Some forums recommend running the program in the current ipython console, but that doesn't help, either.
Is there anything I can do?
Thanks.
I could not get Sypder to stop at break points (inserted with f12). But then in reading the docs I realized I needed to switch to debug mode (Ctrl-f5 or Debug->Debug). This switches the IPython console prompt to:
ipdb>
Once in this mode, break statements work.
I've been trying to find this information online but I'm not getting the answer.
I've used RStudio and Geany for editing files before. Now I'm trying to use ViM to edit python and R files (I know there's RPy, but nothing to do with my problem).
I would like to know how can I have 3 terminals (could also be vim buffers, or screen windows) with one running ViM and the others running R and Python. When I execute a Python script, the terminal (window or buffer) with python shows the output. The same when I run R scripts.
I would appreciate insight on this as this is something that's keeping me from using ViM regularly. I would also consider a solution with terminator terminal multiplexer or guake terminal. Any information about sending code for scripting from one instance to another is welcome.
Are you looking for a way to have a REPL inside Vim? If so, Vim wasn't really designed with that in mind, though there are some plugins that try. Conque is an example.
Some things I use to have a quicker code/run/test iteration with Python:
IPython's %edit feature, which starts editing a script with $EDITOR and will run the script after you exit.
vim-ipython which can send/execute/recieve code via an IPython interpreter.
tmux which allows you to have multiple shells side by side, but with little interaction between them.
Vim-slime is a general-purpose solution to this I'm pretty happy about, it will send blocks of code to any tmux pane, meaning it works for any language.
https://github.com/jpalardy/vim-slime
Your requirements for online information may not have been spelled out in enough detail, since I seem to find a wealth of information on using ViM as an IDE for both R and Python:
R:
http://www.r-bloggers.com/r-with-vim/
http://www.vim.org/scripts/script.php?script_id=2628
http://www.vim.org/scripts/script.php?script_id=1048
Python:
http://wiki.python.org/moin/Vim
http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/
http://dancingpenguinsoflight.com/2009/02/python-and-vim-make-your-own-ide/
Have a look at vim-ipython, a plug-in for Vim.
You need to download the source (linked above), and run the Vim command :source path/to/file/ipy.vim.
Start by running a new IPython session (e.g. using IPython qtconsole or IPython notebook) and then type :IPython into Vim. Your Vim is now connected to the IPython instance you just opened.
You can press F5 to run the whole python script in your Vim, or Ctrl+s to run the current line. Ctrl+s will also run whatever is selected if you're in visual (i.e. 'select') mode.
I use IPython very frequently and happily. Somehow, cutting text from the shell using the keyboard shortcut, Ctrl + X, is broken. Actually, I have a few different installations of IPython. In some of the installations, the shortcut works; in the others, it doesn't work.
What might be the reason for this? Where should I look into?
You say you have multiple instances installed -- are these all on different machines? What operating system(s) are they running? If you access them remotely, what operating system are you running?
Do you get to them using ssh? Do you run something like screen, either locally or remotely, or both? There are lots of things that can interfere with your terminal settings, especially when you're working remotely.
I'm almost certain that iPython doesn't have anything to do with it -- though you might want to check the version numbers, to see if working and non-working environments are running different versions.
More likely, it is something in the terminal emulation layer, but you'll likely have to do some detective work of your own to find out what piece is causing it.
Take it one step at a time -- try to cut from a local shell, to make sure that works. Then connect to a remote machine, and cut from that shell. Start screen, if that's your normal way of doing things, and test from that shell. Then start ipython. If it stops there, then see if you can find another application on the same machine that's linked against gnu readline, and try that. You may find that none of the console apps cut proplerly on that machine, or you may find that they work, but not under screen. Or you may find that something in the terminal settings stops everything from working as soon as you ssh in.
You may also have some luck. if you can find out what terminal the remote machine thinks you are using ( echo $TERM ) by copying the termcap file from a working machine to one that doesn't. That's a bit more involved for these forums, though -- I'd repost at that point on serverfault.com or superuser.com
I hope that at least gives you a starting place -- terminals are finicky, and difficult to get right. Most people seem to not bother, as long as everything mostly works.