Couple of small fixes to consider

In future versions you may want to improve the code inspections to eliminate warnings that should not actually occur.

1.  Python packages, especially hierarchical ones are very messy and Pycharm often fails to find valid modules in the packages.  And some Python modules must be imported even though their name never appears in the source that uses the module–because other imported code references it.  Here is an example.  

In order to create 3D plots with matplotlib you must import as follows:

from mpl_toolkits.mplot3d import Axes3D

but, you'll see no reference to Axes3D in your code.  This class is invoked by using a specific argument in another call:

ax = fig.add_subplot(111, projection='3d')
ax.scatter(X[sel, 0], X[sel, 1], X[sel, 2], s=15, c=colors)

projection='3D' invokes Axes3D so that the scatter plot is a 3d scatter.

In fact, this is so bad it shows up as an error, not as a warning though the code runs and works fine.  It appears that Pycharm can't even see the mpl_toolkits package even though it is clearly present in site-packages.

You could say it shouldn't work this way and I wouldn't argue:  seems to violate Python's own rules, but there you go. This is now the recommend approach per the matplotlib documentation.

Tough to catch cases like this when you can't do static analysis on the source to figure it out.  But, the import shows as unused when it is necessary and is being used.




2. The second case involves Python functions that return multiple arguments.  The convention is to return multiple variables in the return statement as:  return x, y, z      The parentheses for the tuple can be left out.   In the calling return you catch these returns as (x, y, z) = foo(bar).  Generally if you only need the first n returns you can leave out subsequent returned variables.  But, if you are "skipping" a variable then you have to collect the returned variables in order.  By convention, to avoid lots of confusion it is recommended to catch all the returned variables and use the ones you need.  

When you do this, Pycharm flags a warning for a variable defined without usage.  While that can be a useful warning to highlight a possibly misspelled variable in this special case one MUST do it so it seems like the warning should be suppressed.



3.  Here is another example of a member of an imported module that Pycharm thinks is not there:

usage:  palette = plt.cm.hsv(np.arange(K)*int(256/K))

plt by convention results from import matplotlib.pyplot as plt

cm is a module containing mostly functions that return color values, e.g. color maps.  hsv is one of many of those functions.  These are also wrapped by matplotlib top level if you: import maptplotlib as mpl.  Then you can also access mpl.cm.hsv().  Either way, Pycharm won't "see" hsv.

Another sort of tough case caused by Python's messiness.


I am not sure it is important to fix any of these.  I did not notice corresponding inspections that can be turned off for these.  In general, I tend to leave all but the most galling inspections ON:  I'd like to know and then choose to ignore.

Please sign in to leave a comment.