CODEWITHSUNDEEP
pythonimportpycharm
user2261062
user2261062

Reputation:

pyCharm Unresolved reference syntax highlighting

I have a "false" unresolved reference in pyCharm.

I say "false" because the references can actually be executed, my code works fine, so I think it's more a pyCharm problem being unable to resolve the references and marks them in red.

Since I'm quite new to python I would like to understand where the problem comes from.

Basically in the code I'm dealing with, there's a

from PyDAQmx import *

and then in my code I use some of the functions/methods/constants of this library.

DAQmxCreateTask(...)
DAQmxStartTask(...)

PyCharm is marking this references in red with the message ``Unresolved reference DAQmxCreateTask`

If I do 

from PyDAQmx import DAQmxCreateTask, DAQmxStartTask

or I do:

import PyDAQmx as PyDAQmx   
PyDAQmx.DAQmxCreateTask(...)

then the Unresolved reference disapears, so I actually have this two ways of solving my problem, but I want to understand why it happens.

I already tried the pyCharm option of "Invalidate caches and restart" without success.

To my understanding if you do a from foo import * then all functions inside foo should be resolved and callable.

Example.

>> linspace(0,10,3)
Unresolved reference linspace

>> from numpy import *
>> linspace(0,10,3)
array([ 0.,  5., 10.])

So that means that numpy has "something" that allows pycharm to resolve it's functions when imported using * but PyDAQmx lacks this "something"

Could someone guide me in understanding wht this "something" is and how to solve it?

Upvotes: 2

Views: 382

Answers (1)

Rach Sharp
Rach Sharp

Reputation: 2434

PyDAQmx is defining these functions dynamically by adding them to the globals() dict (from the file '/Applications/National Instruments/NI-DAQmx Base/includes/NIDAQmxBase.h'), so I would guess that PyCharm's static code analysis of 3rd party libraries can't identify DAQmxCreateTask due to this.

You can see this in the dynamic definition of __all__ in the PyDAQmx library, while numpy doesn't do this. __all__ restricts the symbols available after a from <thing> import * statement.

I was able to "fix" the unresolved reference by manually adding DAQmxCreateTask to PyDAQmx.__all__ and updating PyCharm skeletons. Not using from PyDAQmx import * will conveniently resolve the issue for you and also be best practice.

There isn't really anything you need to fix as a client of a library doing this kind of dynamic function creation at runtime, but in theory the library maintainer could set __all__ to a manual set of symbols they expect to be defined dynamically from that NIDAQmxBase.h file to resolve the issue for clients.

Upvotes: 1

Related Questions