I have already tried "invalidate cache and restart" (as found here).
And I have already tried turning on "collect run-time types for information for code insight" (as found here).
So I decided to simply remove the error by "ignore unresolved reference" on the print() statements that were complaining (I am not using print 'hello', I am using the function properly).
Now it seems that even actual errors will not get caught, I type in:
prant('hello')
and it doesn't even register the misspelling of "print".
I have my project interpreter set to a version in miniconda environment, which I don't think would change anything, but even changing back to the default version will not get rid of the errors.
In the attached image you can see that "prant('hello') is simply not even registering as an unresolved reference now.
Well, I "fixed" it, although I don't usually consider completely uninstalling the software, then having to delete settings from C:\Users\myname (which weren't caught by uninstall.exe), then making a new directory, creating new .py files and manually copy+pasting the contents of the old ones into it, a "fix".
But on the plus side, it actually does seem to find all my custom imports no problem, which it never did before, and now it actually catches unresolved references properly. It's just a shame I had to go full nuclear just to make it happen. My guess is I FUBAR'd the settings somehow and it kept persisting because those folders in C:\users\myname just wouldn't go away until I deleted them manually.
By the way, I tried both of the things in comments to the original post by downshift and neither of them worked.
Related
I'm sure I'm doing something wrong(i.e. stupid), but running
from stuff.modules import maths
Pylint just keeps giving
No name 'modules' in module 'stuff' pylint(no-name-in-module)
Unable to import 'stuff.modules' pylint(import-error)
My stuff-module is located at /home/abb, so I tried to add both PYTHONPATH="/home/abb" and PYTHONPATH="/home/abb/stuff" to an .env-file, but since it still gives the errors, I think the problem is that I'm also using the stuff-folder as my workspace.
I don't think it's a problem with the .env-file, since I'm also importing from my lib-module located in the same folder as stuff, and this doesn't raise any errors.
(Oh, and if it is important, I'm running this on an SSH-connection)
I had a similar issue. I did 'fix' it by faking another path by using ProjectRootFolder.stuff.modules, saving, and typing again stuff.modules.
I know that it was not a real fix, but from then it worked, also it is stands ever marked with a red under-line.
I explained my issue here.
I had to edit python.analysis.extraPaths.
I tried the .env route and could not get it to work. I actually spent a couple hours on it.
If you go file->preferences->settings or ctrl+, you can search for "extrapath".
Just add your /home/abb/stuff there and it should work.
I am making a keylogger, but every source I see needs that function and it is not working properly.
I tried to update the library and it didn't fix the problem.
all the code is working except the part below.
I have no idea what the below means. pls, help me understand.
if you know a similar function pls help.
I am 14 years old so, I am not experienced will enough.
2 years in C Language. and 1-year web programming. and 1-year python pro.
obj = pyHook.HookManager()
obj.KeyDown = keypressed
obj.HookKeyboard()
pythoncom.PumpMessages()
This is not a Python error message. Unless I am mistaken, you are running PyCharm and you are getting a PyCharm popup when you mouse over the highlighted attribute PumpMessages.
This is nothing to worry about. It is happening because PyCharm's analysis doesn't always know how to examine Python extensions in DLLs. As PyCharm itself says,
This inspection detects names that should resolve but don't. Due to dynamic dispatch and duck typing, this is possible in a limited but useful number of cases.
One of the limitations of this inspection is functions in DLLs, which are dynamically dispatched.
If you look in the file pythoncom.py you will see that it doesn't in fact contain a definition of the function PumpMessages, only two lines that import pythoncom3x.dll. The function definition lives in that DLL and PyCharm can't find it there, because it would have to execute the code to establish where to look. The message is a false alarm.
If it bothers you, put the caret on the highlight, hit alt-Enter, click the lightbulb icon, and select one of the options to disable reporting of unresolved references, either for the function or for the entire pythoncom module. Otherwise just ignore it.
To turn it back on, hit ctrl-alt-S (Settings), choose Editor | Inspections | Python | Unresolved references.
So if your program isn't working as expected, look for the cause elsewhere. This warning is not the problem.
I'm using PyCharm Community Edition 4.5.4, and I hate how it notifies me of every little "mistake" I make even when I have full intention of fixing it within 30 seconds.
My style is to kind of write everything at once (instead of finishing one thing before moving to the other), and thus every second word in my code gets highlighted as variable 'x' is not used or Unresolved reference 'x' because I already moved to an other section of my code, intenting to finish the for loop later. If I do something like:
for x in my_list:
pass
And then move to define my_list on top of the file, it will instantly highlight Local variable 'x' is not used. I wish to write my whole code freely, and then after hitting save, I wanna know what mistakes I made.
Is there any way to disable the PEP8 checker, so it would only check when I actually save the file, instead of when I type anything at all?
I have had problems with this issue too.
Unfortunately, there seems to be no documented way of doing what you're requesting. The PyCharm Articles on Code Inspection and Configuring Inspections really don't hint at any such possibility.
Additionally the config file in ~/.PyCharm40/config/inspection/Default.xml isn't what you would call rich in options (note: I have no idea if more options exist, couldn't really find appropriate documentation).
Since pep8.py is apparently ran continuously as a background process in PyCharm, I also checked whether a configuration of these processes was possible. Unfortunately (again), no useful results were found.
To make things worse, there seems to be no relevant plugin available in their plugin repository to allow for further tweaking of the inspection tool.
The other option I tried was by changing the settings in PyCharm and resort to manual calls to pep8. I unselected the inspections for pep8 from Settings | Editor | Inspections | Python tab and then ran the manual inspection by pressing Ctrl + Alt + Shift + I and entering the two pep options. It does not seem to catch the same coding convention errors.
You probably have two options now, one is switching to another IDE as Adam Smith suggested (or noted, actually) and second is trying to maybe get some help on the PyCharm forum.
Say I'm working with the 'requests' Python library.
req = requests.get("http://google.com")
Now after this, if I type req., I'm supposed to get a list of all methods I can access. But for some reason I don't, even if I manually press Ctrl+Space.
If I try this in iPython, I get autocomplete recommendations. Even if I try it via the built in Python console in PyCharm, I get recommendations.
Why's this happening?
As Python is a dynamically typed language, you need to ensure it can work out what type things are, and inspect on the libraries on your system correctly. Try to make sure it's obvious what type the object is in your code.
One good way as of PyCharm 2.7 (back when versions were numbers) is to enable runtime type detection - PyCharm hooks into your program while it runs (while debugging), and checks the types of variables as they are used.
You can enable this by going to settings, going to the "Build, Execution, Deployment" section and then the "Python Debugger" subsection and enabling "Collect run-time types information for code insight".
Obviously it is worth noting that this isn't perfect - if you make changes, this won't be updated til the code is executed, and it can only tell you about values it has seen - other code paths you haven't tried could set other types.
You can also 'tell' PyCharm by using Epydoc or Sphinx style docstrings that contain information about parameter and return value types. PyCharm will use these to improve it's inspections.
Python also gained support for function annotations as of Python 3. These can be used for type hints as per PEP 484. See the typing module for more. This is more formal, so it can also be used for tools like mypy which a type checker that can programmatically check these types for consistency, giving Python a TypeScript-style optional static typing.
Python is a dynamically typed language, which means that the "get" function does not declare its return type. When you're entering code in IPython or in the PyCharm console, the code is actually being executed, and it's possible to inspect the object instance in the running interpreter and to get the list of its methods. When you're entering code in PyCharm or in any other Python IDE, it is not executed, and it's only possible to use static analysis to infer the return type of the method. This is not possible in all cases.
PyCharm has no idea what the dict contains if you fill it dynamically. So you have to hint PyCharm about the keys of dict beforehand. Prodict does exactly this to hint PyCharm, so you get code completion.
First, if you want to be able to access the response object, then you have to get a json response and convert it to dict. That's achieved with .json() method of requests like this:
response = requests.get("https://some.restservice.com/user/1").json()
OK, we loaded it to a dict object, now you can access keys with bracket syntax:
print(response['name'])
Since you ask for auto code completion, you certainly need to hint PyCharm about the keys of dict. If you already know the respone schema, you can use Prodict to hint PyCharm:
class Response(Prodict):
name: str
price: float
response_dict = requests.get("https://some.restservice.com/user/1").json()
response = Response.from_dict(response_dict)
print(response.name)
print(response.price)
In the above code, both name and price attributes are auto-complated.
If you don't know the schema of the response, then you can still use dot-notation to access dict attributes like this:
response_dict = requests.get("https://some.restservice.com/user/1").json()
response = Prodict.from_dict(response_dict)
print(response.name)
But code-completion will not be available since PyCharm can't know what the schema is.
What's more is, Prodict class is derived directly from dict, so you can use it as dict too.
This is the screenshot from Prodict repo that illustrates code completion:
Disclaimer: I am the author of Prodict.
if will just detect methods or variables and... with write some part of it:
File->Setting -> Editor -> General -> Code Completion
in top of opened window , unCheck [ Mach Case ]
It's an old question but probably all the provided answers missed the mark by a margin as wide as Sun's distance to Betelgeuse (none of the answers is accepted and #user1265125 is an active guy with 8 yrs here and more cred than me).
As it happens, I've just had exactly the same problem as OP and the solution was:
A NON-ASCII CHAR SOMEWHERE IN THE PROJECT'S FOLDER PATH
Seriously, PyCharm devs...[doubleFacepalm]
In my case the solution is to reset the settings, everething else wasn`t working for me.
"From the main menu, select File | Manage IDE Settings | Restore Default Settings.Alternatively, press Shift twice and type Restore default settings."
I had a similar problem. Only functions I had already used were suggested and only as plain text and not recognised as methods.
What fixed that for me was deleting the /.idea folder in the project directory. (Afterwards you will have to set your run configurations again)
With the latest version update to 2022.2, even auto-complete stopped working for me. After quite a bit of reading articles, I just found the https://youtrack.jetbrains.com/issue/PY-50489 issue which was the root problem. The old plugins were pending update, after that, the code completion issue was fixed.
So, try and check if you are facing the same problem, if the plugins are up to date in Settings —> Plugins.
I am working on a project using python 2.7.2, sqlalchemy 0.7, unittest, eclipse 3.7.2 and pydev 2.4. I am setting breakpoints in python files (unit test files), but they are completely ignored (before, at some point, they worked). By now i have upgraded all related software (see above), started new projects, played around with settings, hypnotized my screen, but nothing works.
The only idea i got from some post is that it has something to de with changing some .py file names to lower case.
Does anyone have any ideas?
added: I even installed the aptana version of eclipse and copied the .py files to it => same result; breakpoints are still ignored.
still no progress: I have changed some code that might be seen as unusual and replaced it with a more straightforward solution.
some more info: it probably has something to do with module unittest:
breakpoints in my files defining test suites work,
breakpoints in the standard unittest files themselves work
breakpoints in my tests methods in classes derived from unittest.TestCase do not work
breakpoints in my code being tested in the test cases do not work
at some point before i could define working breakpoints in test methods or the code being tested
some things i changed after that are: started using test suites, changed some filenames to lowercase, ...
this problem also occurs if my code works without exceptions or test failures.
what I already tried is:
remove .pyc files
define new project and copy only .py files to it
rebooted several times in between
upgraded to eclipse 3.7.2
installed latest pydev on eclipse 3.7.2
switch to aptana (and back)
removed code that 'manually' added classes to my module
fiddled with some configurations
what I can still do is:
start new project with my code, start removing/changing code until breakpoints work and sort of black box figure out if this has something to do with some part of my code
Does anyone have any idea what might cause these problems or how they might be solved?
Is there any other place i could look for a solution?
Do pydev developers look into the questions on stackoverflow?
Is there an older version of pydev that i might try?
I have been working with pydev/eclipse for a long time and it works well for me, but without debugging i'd forced to switch IDE.
In answer to Fabio's questions below:
The python version is 2.7.2,
The sys.gettrace gives None (but I have no idea what in my code could influence that)
This is the output of the debugger after changing the suggested parameters:
pydev debugger:
starting
('Executing file ', 'D:\\.eclipse\\org.eclipse.platform_3.7.0_248562372\\plugins\\org.python.pydev.debug_2.4.0.2012020116\\pysrc\\runfiles.py')
('arguments:', "['D:\\\\.eclipse\\\\org.eclipse.platform_3.7.0_248562372\\\\plugins\\\\org.python.pydev.debug_2.4.0.2012020116\\\\pysrc\\\\runfiles.py', 'D:\\\\Documents\\\\Code\\\\Eclipse\\\\workspace\\\\sqladata\\\\src\\\\unit_test.py', '--port', '49856', '--verbosity', '0']")
('Connecting to ', '127.0.0.1', ':', '49857')
('Connected.',)
('received command ', '501\t1\t1.1')
sending cmd: CMD_VERSION 501 1 1.1
sending cmd: CMD_THREAD_CREATE 103 2 <xml><thread name="pydevd.reader" id="-1"/></xml>
sending cmd: CMD_THREAD_CREATE 103 4 <xml><thread name="pydevd.writer" id="-1"/></xml>
('received command ', '111\t3\tD:\\Documents\\Code\\Eclipse\\workspace\\sqladata\\src\\testData.py\t85\t**FUNC**testAdjacency\tNone')
Added breakpoint:d:\documents\code\eclipse\workspace\sqladata\src\testdata.py - line:85 - func_name:testAdjacency
('received command ', '122\t5\t;;')
Exceptions to hook : []
('received command ', '124\t7\t')
('received command ', '101\t9\t')
Finding files... done.
Importing test modules ... testAtomic (testTypes.TypeTest) ... ok
testCyclic (testTypes.TypeTest) ...
The rest is output of the unit test.
Continuing from Fabio's answer part 2:
I have added the code at the start of the program and the debugger stops working at the last line of following the method in sqlalchemy\orm\attributes.py (it is a descriptor, but how or whther it interferes with the debugging is beyond my current knowledge):
class InstrumentedAttribute(QueryableAttribute):
"""Class bound instrumented attribute which adds descriptor methods."""
def __set__(self, instance, value):
self.impl.set(instance_state(instance),
instance_dict(instance), value, None)
def __delete__(self, instance):
self.impl.delete(instance_state(instance), instance_dict(instance))
def __get__(self, instance, owner):
if instance is None:
return self
dict_ = instance_dict(instance)
if self._supports_population and self.key in dict_:
return dict_[self.key]
else:
return self.impl.get(instance_state(instance),dict_) #<= last line of debugging
From there the debugger steps into the __getattr__ method of one of my own classes, derived from a declarative_base() class of sqlalchemy.
Probably solved (though not understood):
The problem seemed to be that the __getattr__ mentioned above, created something similar to infinite recursion, however the program/unittest/sqlalchemy recovered without reporting any error. I do not understand the sqlalchemy code sufficiently to understand why the __getattr__ method was called.
I changed the __getattr__ method to call super for the attribute name for which the recursion occurred (most likely not my final solution) and the breakpoint problem seems gone.
If i can formulate the problem in a consise manner, i will probably try to get some more info on the google sqlalchemy newsgroup, or at least check my solution for robustness.
Thank you Fabio for your support, the trace_func() function pinpointed the problem for me.
Seems really strange... I need some more info to better diagnose the issue:
Open \plugins\org.python.pydev.debug\pysrc\pydevd_constants.py and change
DEBUG_TRACE_LEVEL = 3
DEBUG_TRACE_BREAKPOINTS = 3
run your use-case with the problem and add the output to your question...
Also, it could be that for some reason the debugging facility is reset in some library you use or in your code, so, do the following: in the same place that you'd put the breakpoint do:
import sys
print 'current trace function', sys.gettrace()
(note: when running in the debugger, it'd be expected that the trace function is something as: <bound method PyDB.trace_dispatch of <__main__.PyDB instance at 0x01D44878>> )
Also, please post which Python version you're using.
Answer part 2:
The fact that sys.gettrace() returns None is probably the real issue... I know some external libraries which mess with it (i.e.:DecoratorTools -- read: http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html) and have even seen Python bugs and compiled extensions break it...
Still, the most common reason it breaks is probably because Python will silently disable the tracing (and thus the debugger) when a recursion throws a stack overflow error (i.e.: RuntimeError: maximum recursion depth exceeded).
You can probably put a breakpoint in the very beginning of your program and step in the debugger until it stops working.
Or maybe simpler is the following: Add the code below to the very beginning of your program and see how far it goes with the printing... The last thing printed is the code just before it broke (so, you could put a breakpoint at the last line printed knowing it should be the last line where it'd work) -- note that if it's a large program, printing may take a long time -- it may even be faster printing to a file instead of a console (such as cmd, bash or eclipse) and later opening that file (just redirect the print from the example to a file).
import sys
def trace_func(frame, event, arg):
print 'Context: ', frame.f_code.co_name, '\tFile:', frame.f_code.co_filename, '\tLine:', frame.f_lineno, '\tEvent:', event
return trace_func
sys.settrace(trace_func)
If you still can't figure it out, please post more information on the obtained results...
Note: a workaround until you don't find the actual place is using:
import pydevd;pydevd.settrace()
on the place where you'd put the breakpoint -- that way you'd have a breakpoint in code which should definitely work, as it'll force setting the tracing facility at that point (it's very similar to the remote debugging: http://pydev.org/manual_adv_remote_debugger.html except that as the debugger was already previously connected, you don't really have to start the remote debugger, just do the settrace to emulate a breakpoint)
Coming late into the conversation, but just in case it helps. I just run into a similar problem and I found that the debugger is very particular w.r.t. what lines it considers "executable" and available to break on.
If you are using line continuations, or multi-line expressions (e.g. inside a list), put the breakpoint in the last line of the statement.
I hope it helps.
Try removing the corresponding .pyc file (compiled) and then running.
Also I have sometimes realized I was running more than one instance of a program.. which confused pydev.
I've definitely seen this before too. Quite a few times.
Ran into a similar situation running a django app in Eclipse/pydev. what was happening was that the code that was running was the one installed in my virtualenv, not my source code. I removed my project from my virtual env site-packages, restarted the django up in the eclipse/pydev debugger and everything was fine.
I had similar-sounding symptoms. It turned out that my module import sequence was rexec'ing my entry-point python module because a binary (non-Python) library had to be dynamically loaded, i.e., the LD_LIBRARY_PATH was dynamically reset. I don't know why this causes the debugger to ignore subsequent breakpoints. Perhaps the rexec call is not specifying debug=true; it should specify debug=true/false based on the calling context state?
Try setting a breakpoint at your first import statement being cognizant of whether you are then s(tep)'ing into or n(ext)'ing over the imports. When I would "next" over the 3rdparty import that required the dynamic lib loading, the debug interpreter would just continue past all breakpoints.