This is absolutely frustrating, but I am not sure if the following is an issue only on my machine or with IDLE in general.
When attempting to print a long list in the shell, and that could happen by accident while debugging, the program crushes and you have to restart it manually.
Even worse, if you have a few editor windows open, it always spawns a few sub-processes, and each of these has to be manually shut down from the task manager.
Is there any way to avoid that?
I am using Python 3, by the way.
The Squeezer extension addresses this problem. Instead of displaying the long text (which is the source of the slow-down), Squeezer captures the output and displays a button instead. You have the option of expanding the contents or viewing it in Notepad.
Squeezer is included in IdleX, which you may find useful.
It seems tk needs to write a lot of data in the shell frame, this takes a lot of time and when the list is long then it becomes unresponsive.
I did:
>>a = range(n)
>>print(list(a))
It was OK for n = 100 or n = 1000. After that point things started being slow. For n as low as 10000, moving the page up and down becomes very, very slow.
I suspect that there is no solution. For small values of n probably it would help to clear() the window but unfortunately idle have not implemented any method to clear the shell. I dont understand why because it should not be difficult...
Edit 2012:
During the last months IDLE behavior and functionality got many important improvements through the collection of extensions and plugins provided by IdleX .
Accidental printing of high amounts of data is not a problem anymore. When IdleX detects such a situation it shows a warning indicating the existence of the data instead of printing it. Righ-clicking on the warning produces a preview of the data, not in idle shell but on the system text editor (notepad in windows). In this way the shell doesnt get cluttered with data nor slow down.
Related
I'm doing experience with my first small applications, essentially data viewers based on Pandas and matplotlib, using PyQt for the GUI part.
What I find now difficult is to understand what goes wrong in my code, because the error does not get propagated to the iPython console I launch my script from.
It simply won't do what's expected, but there is no information as to 'why'.
To fix ideas, let's say I have a button that should plot a certain curve to the canvas. If there's a fail in the indexing operation of the data, therefore nothing can be plotted, then nothing will appear on the canvas, but I'll get no traceback that actually index so-and-so wasn't to be found.
Using the debugger proves quite cumbersome, too.
I had a situation where, while running my main(), I could interact with the IPython shell and do things like:
main.my_plot_function()
from which I would get a standard output, and see what is wrong. Although sub-optimal, this did the trick.
I had to reset Spyder this morning (wasn't launching on Windows), and since then, when I launch my script, the console is unresponsive. So I can't do `main.my_plot_function()' anymore.
Generally speaking, is there a way to instruct Spyder or the console that I want to see what's going on in the background? Some "verbose" switch?
I am not sure what you mean by wanting to know what's going on in the background. I assume that you wish to know at many points in the code, what the variable types and values are and/or where the current point of execution is.
There are two options:
1) Use print statements wherever you need to know what's going on. For example, if you have a plot function, simply put some print statements inside the function to print out the sizes of the lists/arrays being plotted etc. You can also look for useful functions in this regard, i.e., type() to print out the type of a variable to make sure it is what you think it is, print(locals()) to print names and values of all local variables etc.
2) Use pdb to introduce break points and run your main script from the command line. This will stop the script execution where you want and from the pdb console, you can inspect the data-structures. There are of course other debuggers you can use, such as pudb (with a basic GUI and some extra features than pdb).
There is no general "verbose" mode in spyder or any other Python IDE I know of.
When typing the following code into the editor window, only some of the available items for autocomplete show up. That is to say that it should show .loc as an option but doesn't.
import pandas as pd
df = pd.read_csv('somecsvfile.csv')
df.
code completion in editor window
When using the console in PyCharm with the same code, the full list shows up. (See the attached images)
code completion with the full list
I have invalidated caches and restarted. Further, it seems like another recommendation was to turn on Python Debugger -> Collect run-time types information for code insight. I did that as well and still nothing when in the editor window.
What really confuses me is that the code completion works in the console, but not the editor.
Any help would be greatly appreciated!
When you run it in the console it knows the type of df because it actually has it right there. It can even run dir(df) to know exactly what names are available. In the editor it isn't running the code so it has to guess the type by inspecting pd.read_csv which is much harder (often even impossible) because Python is so dynamic.
I used to have this same problem. This was only happening for me in Linux. Note that this is possible and actually standard behavior in windows, so it can be done. Not sure if it is done using static analysis or a similar method.
I have since been able to fix it, I think what did it was defining the correct interpreter not only in the running/debugging configuration, but also in the defaults of the project (check File-->settings-->Project Interpreter and File-->default settings-->Project Interpreter)
I have now moved to the next problem, which is that auto-complete works for Python Console and File editing, but weirdly enough does not work for Debugging!...
I'm trying hard to like IPython Notebook, but maybe because I'm so used to writing code in vi and executing it at the command line I'm finding some of its defaults challenging. Can anything be done (perhaps in a configuration file somewhere) about the following?
I'd like %hist to output line numbers by default without having to remember the -n and without having to set up an alias every time.
How do I set %automagic to "off" by default to stop IPython polluting my namespace with its un-percented magics and shell commands? I know I can use the --no-import-all option with --pylab option: is there an equivalent --no-automagic option?
It drives me mad that I'm never quite sure what is the status of the objects bound to my variable names: changing and running a cell beneath the one I'm using can alter an object I'm referring to in the current cell. To avoid this, I've got into the habit of using Run All or Run All Above, but that sometimes repeats lengthy calculations and reimports stuff I'd rather not bother with: can I flag some cells to be not-rerun by Run All?
Can I get vi-style key-bindings for editing cells?
Why does IPython notebook hang my browser if the kernel is using lots of memory? I thought they were separate processes with the kernel just reporting back its results.
(Please try to ask one question per question - SO is designed to work that way. However, I'm not feeling so mean that I'd refuse to answer)
I don't think the behaviour of %hist is configurable, sorry.
Set c.InteractiveShell.automagic = False in your config files.
There has been some discussion of a %%cache cell magic that could avoid re-running long running cells by storing values computed in that cell. It has not been implemented yet, though.
Yes: https://github.com/ivanov/ipython-vimception
It shouldn't hang just because of kernel memory use - if your code is producing a lot of output, though, that can hang the browser because adding lots of things to the DOM gums it up.
I'm working on a python project that spans across multiple files and directories. Here's my workflow:
Run main python script
Main script calls some functions in other files
Functions in other files/directories execute
In the middle of execution, there is a bug in one of the functions, but I find the bug only after the main script finishes. Sometimes, there may not be a bug, but rather some parameter that needs tweaking.
I go back and fix the bug/make the necessary tweaks and re-run the main program and this time it executes fine.
Obviously, this workflow is terribly inefficient as considerable amount of code (that runs prior to the buggy function) gets re-executed. What would be ideal is to run the program in ipython and after discovering the issue and making the necessary changes, restart from the place where the buggy function executions starts and not from the beginning. I'm not sure how to achieve this and any help would be much appreciated.
I know how to rerun lines from ipython history (%rerun) and how to ensure autoreload of changed files in ipython, but in this case, I can't really type out the lines of code into ipython. Writing unit tests may not always be feasible, so I need an alternate solution. My use case is something similar to setting a "breakpoint" and then re-executing code past the breakpoint multiple times so as to avoid re-executing the code prior to the breakpoint more than once, while ensuring that all the necessary variables (until that stage) are correctly populated. One final condition is that I may not be able to use an IDE and vim is the only editor available across all the environments I work with.
You could start writing test cases for every function and try to debug each function separately instead of the whole program/script.
There is a python unittest-module: https://docs.python.org/3.4/library/unittest.html and a lot of tutorials like (just an example): http://docs.python-guide.org/en/latest/writing/tests/
It seems annoying writing tests but thinking about test cases gives deeper understanding of "How should the function behave if...".
You could use the code module to include "breakpoints" in your code
import code
# ... later in your program add
code.interact(local=locals()) # enter python interpreter at this point (ctrl+D to continue execution)
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.