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!...
Related
While using boto3 client, PyCharm autocompletion is not giving complete list of methods. I have gone through several posts regarding similar issues, but nothing worked out so far. Can anyone suggest a solution here? Attaching a screenshot for reference.
**If code completion doesn't work, this may be due to one of the following reasons:**
1.The Power Save Mode is on (File | Power Save Mode). Turning it on minimizes power consumption of your laptop by eliminating the background operations, including error highlighting, on-the-fly inspections, and code completion.
2.Your file doesn't reside in a content root , so it doesn't get the required class definitions and resources needed for code completion.
3.Refer to Configuring Project Structure for more details.
4.A file containing classes and functions that you want to appear in completion suggestions list is marked as a plain text file.
5.External libraries that contain functions that you want to appear in the completion suggestions list are not added as dependencies or global libraries.
I hope this solves your Problem.
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.
I have been fooling around for about a month with python now and something is bothering me.
I use the python(x,y) toolkit, which comes with the neat Spyder IDE.
My question concerns the UMD (User module deleter) of Spyder.
I found this graphics module on the internet, which helps one to do some simple graphic stuff in a python script (as far as I understand).
It is not like i'm stuck, but when I execute the folowing code:
import pylab as p
import graphics as g
window = g.GraphWin("tryout", 600, 600)
window.close()
print p.sqrt(4)
The output is:
>>>runfile(r'C:\some\folders\tryout.py', wdir=r'C:\some\folders')
>>>UMD has deleted: graphics
>>>2.0
line 1 is obviously o.k. and so is line 3, but I don't get line 2.
Also, the provoked window flashes in and out of the screen, as it should.
Line 2 doesn't seem to do any harm, and i can perfectly rerun the file as many times as I wan't, but I want to know where it is comming from.
AFAIK UMD forces the interpreter to reload a module everytime a script is run.
Does the displayed message mean that 'it' has deleted the references to the module, because it isn't used anymore, or is it something else? Or does it mean something is wrong, and will it 'hurt' my code should I add more afterwards?
Note: first question, so please comment the crap out of it to help me improve my asking skills.
EDIT: i tried shifting around the test line print p.sqrt(4), and found out that it doesn't matter where I put it. If its the first line after importing the modules, it still raisses the message before showing sqrt(4)
Short Answer:
Perhaps deleted is not the best word in the message you mention. It should be reloaded, which is what UMD is really doing and because is way less confusing. I'll fill an issue for this in our issue tracker.
Long answer:
UMD reloads not only your script but also all the local modules it depends on. By local I mean modules outside your Python installation and over which you have writing permissions.
The idea is that next to your script, perhaps you have developed a library of auxiliary functions to go with it. So you most probably want to reload that library too, so that any changes to it are reflected at run time.
I know this is not your case, so if you want to remove that message, you can go to:
Tools > Preferences > Console > Advanced settings > User Module Deleter
and deactivate the option
Show reloaded modules list
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.
I try Eclipse+PyDev pair for some of my work. (Eclipse v3.5.0 + PyDev v1.5.6) I couldn't find a way to expose all of my variables to the PyDev console (Through PyDev console -> Console for current active editor option) I use a simple code to describe the issue. When I step-by-step go through the code I can't access my "x" variable from the console. It is viewed on Variables tab, but that's not really what I want.
Any help is appreciate.
See my screenshot for better description:
EDIT:
Assume adding a simple func like:
def myfunc(x):
return x**x
When I debug with the function added in the code I can access myfunc from the console easily. (Type myfunc and it will be available after this automatic execution:
>>> from part2.test import myfunc
>>> myfunc
Then when I do myfunc(5) it acts just like in the Python interpreter. It would be so useful to access variables in the similar fashion for debugging my code. I have big arrays and I do various tests and operations during debug process. Like:
Get my x and do x.sum(), later do x[::10], or transpose operate with other arrays observe results, experiment etc...
Hope there will be a better solution.
Update:
In the latest PyDev versions, it's possible to right-click a frame in the stack and select PyDev > Debug console to have the interactive console with more functions associated to a context during a debug session.
Unfortunately, the actual interactive console, which would be the preferred way of playing with code (with code-completion, etc -- http://pydev.org/manual_adv_interactive_console.html) has no connection to a debug session right now (this is planned but still not implemented).
Still, with the 'simpler' console available, you are still able to interactively inspect and play with the variables available in a breakpoint scope: http://pydev.org/manual_adv_debug_console.html (which is the same as you'd have with pdb -- it's just a matter of typing code in the available console after a breakpoint is hit).
Cheers,
Fabio
For this sort of exploratory debugging I like to use pdb, the batteries-included debugger. I haven't used it inside PyDev so I don't know how it would all fit together. My guess is it will do what you expect it to. An example of its usage:
import pdb
def myfunc(x):
pdb.set_trace()
return x**x
This will break right before executing the return statement, and it allows you to use full Pythonic statements to figure out what's going on. I use it like an interactive print statement: setting the place where I want to dive in, examining values and figuring results, and stepping through to watch it happen. Perhaps this is a lazy way of debugging, but sometimes you need more information before you can make less-lazy decisions :-)
The page I usually reference is at Python Conquers The Universe which also links a few other sources of information.