I hope this makes sense. When using the IDLE python shell and typing the commands one by one, there is an output or response to most lines of code typed.
When writing a script and then running that script in IDLE I don't get to see the same output in the shell, is there a way of enabling it, or a line of code to add to my script so it displays?
Thanks
A feature of both standard interactive mode and the IDLE Shell (and presumably of other Python IDEs) is that the value of expressions entered in response to the >>> or other interactive prompt is echoed on a line below.
When running a script, the value of an expression statement is not printed. This is because such expressions are often included in files for their side effects, and because output may not be wanted. One must explicitly print() or sys.stdout.write() to see the result . So
>>> 2+3
5
must be written, for instance, as print(2+3) in a program executed all at once, whether from any editor or from a command line. (In other words, this question is not really IDLE specific, although it is a common one from beginners, who often use IDLE.)
If this is not your problem, we need much more information to help.
Related
I am new to Python, have some experience in MatLab and r. My question is: Is it possible to run part of the code in .py block by block (line by line)?
In r or Matlab, I can first have some data and variables loaded in the memory first. Then experimentally I can run a line or two to try out the syntax... this is particularly useful for new learners I believe. I know there is something called the iPython which can execute Python code line by line however this is not what I am after. Thanks.
Since ipython has already been discounted, I'm not sure this answer will be better. But I will tell you the two things that I do.
I drop into the debugger at the point where I want to "try out" something, so the code will run up to that point, and then drop me into the debugger. You do this simply by inserting this code at that point:
import pdb; pdb.set_trace()
Once you've done what needs to be done, you can either press q to quit, or c to continue running the process.
I use the -i option to python. This enters interactive mode at the end of your python code. This is useful if you want to set up a bunch of data structures, and try out some code on it, instead of typing all of it into a python shell first. (that might be why you rejected ipython?)
I think what you need is a debugger.
You can use the pydev plugin for Eclipse which has a debugger.
Another option is pdb as already suggested but it's not very easy to use.
I'm a new Python user, and I'm sure this is a really basic question, but I can't find the answer anywhere. When people post Python code online it is often formatted like this:
In [1]: # some stuff
Out[1]:
# some more stuff
What are the In's, Out's, and the numbers? And why does my Python console not behave like that?
They are not Python code. They are IPython prompts, a popular Python add-on interactive shell.
Each line of code executed on the interactive prompt (denoted by In) is numbered, and so is the output produced (denoted by Out). You can then instruct IPython to refer back to those inputs and outputs for re-running code or re-using output.
See the Input caching system documentation>
IPython offers numbered prompts (In/Out) with input and output caching (also referred to as ‘input history’). All input is saved and can be retrieved as variables (besides the usual arrow key recall), in addition to the %rep magic command that brings a history entry up for editing on the next command line.
If I'm using a python interpreter under EMACS, then I've got various ways of evaluating code, for instance just typing it in at the REPL (Inferior Python) If that code produces too much output, then EMACS freezes solid and has to be killed.
This will do it, for instance.
[[[False] * 200 for i in range(3)] for j in range(200)]
There's no problem at all if python's running in a terminal. It just prints out False 120000 times and gives me the prompt back.
Is there any way to either limit the amount of output the inferior python process produces, or to get EMACS not to explode when faced with large outputs?
In clojure, for example, I can use *print-length* and *print-level* to solve this exact same problem.
Repeated calculations by comint-mode are considered the cause.
As for python-mode.el checked in a solution WRT
https://bugs.launchpad.net/python-mode/+bug/1253907
which makes it work from inside a print in source-buffer, not from shell.
It comes with a couple of new commands prefixed "py-fast-".
Alternatively new option py-fast-process-p must be `t'.
Maybe give it a try:
https://launchpad.net/python-mode
However, with python-mode.el and M-x IPython RET, it doesn't occur, runs nearly as fast as in console.
BTW ipython.el should not be needed.
I am trying to call an .exe file that's not in my local Python directory using subprocess.call(). The command (as I type it into cmd.exe) is exactly as follows: "C:\Program Files\R\R-2.15.2\bin\Rscript.exe" --vanilla C:\python\buyback_parse_guide.r
The script runs, does what I need to do, and I have confirmed the output is correct.
Here's my python code, which I thought would do the exact same thing:
## Set Rcmd
Rcmd = r'"C:\Program Files\R\R-2.15.2\bin\Rscript.exe"'
## Set Rargs
Rargs = r'--vanilla C:\python\buyback_parse_guide.r'
retval = subprocess.call([Rcmd,Rargs],shell=True)
When I call retval in my Python console, it returns 1 and the .R script doesn't run, but I get no errors. I'm pretty sure this is a really simple syntax error... help? Much thanks!
To quote the docs:
If shell is True, it is recommended to pass args as a string rather than as a sequence.
Splitting it up (either manually, or via shlex) just so subprocess can recombine them so the shell can split them again is silly.
I'm not sure why you think you need shell=True here. (If you don't have a good reason, you generally don't want it…) But even without shell=True:
On Windows, if args is a sequence, it will be converted to a string in a manner described in Converting an argument sequence to a string on Windows. This is because the underlying CreateProcess() operates on strings.
So, just give the shell the command line:
Rcmd = r'"C:\Program Files\R\R-2.15.2\bin\Rscript.exe" --vanilla C:\python\buyback_parse_guide.r'
retval = subprocess.call(Rcmd, shell=True)
According to the docs, Rscript:
… is an alternative front end for use in #! scripts and other scripting applications.
… is convenient for writing #! scripts… (The standard Windows command line has no concept of #! scripts, but Cygwin shells do.)
… is only supported on systems with the execv system call.
So, it is not the way to run R scripts from another program under Windows.
This answer says:
Rscript.exe is your friend for batch scripts… For everything else, there's R.exe
So, unless you have some good reason to be using Rscript outside of a batch script, you should switch to R.exe.
You may wonder why it works under cmd.exe, but not from Python. I don't know the answer to that, and I don't think it's worth digging through code or experimenting to find out, but I can make some guesses.
One possibility is that when you're running from the command line, that's a cmd.exe that controls a terminal, while when you're running from subprocess.call(shell=True) or os.system, that's a headless cmd.exe. Running a .bat/.cmd batch file gets you a non-headless cmd, but running cmd directly from another app does not. R has historically had all kinds of complexities dealing with the Windows terminal, which is why they used to have separate Rterm.exe and Rcmd.exe tools. Nowadays, those are both merged into R.exe, and it should work just fine either way. But if you try doing things the docs say not to do, that may not be tested, it's perfectly reasonable that it may not work.
At any rate, it doesn't really matter why it works in some situations even though it's not documented to. That certainly doesn't mean it should work in other situations it's not documented to work in, or that you should try to force it to do so. Just do the right thing and run R.exe instead of Rscript.exe.
Unless you have some information that contradicts everything I've found in the documentation and everywhere else I can find, I'm placing my money on Rscript.exe itself being the problem.
You'll have to read the documentation on the invocation differences between Rscript.exe and R.exe, but they're not identical. According to the intro docs,:
If you just want to run a file foo.R of R commands, the recommended way is to use R CMD BATCH foo.R
According to your comment above:
When I type "C:\R\R-2.15.2\bin\i386\R.exe" CMD BATCH C:\python\buyback_parse_guide.r into cmd.exe, the .R script runs successfully. What's the proper syntax for passing this into python?
That depends on the platform. On Windows, a list of arguments gets turned into a string, so you're better off just using a string so you don't have to debug the joining; on Unix, a string gets split into a list of arguments, so you're better off using a list so you don't have to debug the joining.
Since there are no spaces in the path, I'd take the quotes out.
So:
rcmd = r'C:\R\R-2.15.2\bin\i386\R.exe CMD BATCH C:\python\buyback_parse_guide.r'
retval = subprocess.call(rcmd)
I'm experimenting with debugging my python from the raw pdb program rather than running pdb though emacs (which tracks the current line with a marker in the text display of the code). It's slightly annoying that the list command l in pdb only displays a few lines of code, I would rather have it fill my terminal with all the code of the current function up to the current line.
I know I can do this manually by looking at the line numbers are typing l 50,100 (where 100 is the current line) but this is time consuming and I'd like to set this up to work automatically.
I wonder if there is a way to define a pdb command to do this? I'm guessing it would need to (1) access the number of the current line, N; then (2) execute "l N-50, N". I've searched around a lot but can't find anyone who has done this before. Perhaps there is a way to access the pdb module's own internals to get the line number?
(Or a roundabout way would be to write something that calls list once, parses the output to extract the current line, then executes a new list command, I wonder if anyone has done this already? Is this how IDEs manage to get the current line information from pdb or are they using its internals I wonder?)
You could probably extend the PDB class, but the extension interface isn't documented very well.
I'd instead recommend using pdb++ and its sticky feature which pretty much does what you want, if I understood your use case correctly.