np.errstate triggers error warning

[dzanaga]

Environment data

• Language Server version: ms-python.vscode-pylance-2020.6.1
• OS and version: Linux CentOS (Remote with SSH Extension)
• Python version: Anaconda 3.7.6
• numpy: 1.18.5

Expected behaviour

This

with np.errstate(divide='ignore'):

triggers an error warning in the problems pane:

No parameter named "divide" Pylance [522, 22]

while the line runs without issues.

[dzanaga]

I also have an error while loading the server, I don't know if this might be connected. I opened an issue with the full log: #17

[dzanaga]

Same issue with:

widgets.Button(description="Prev")

Argument missing for parameter "widget"
No parameter named "description"

[jakebailey]

Is your typeCheckingMode set to the default ("off"), or are you using one of the stricter rulesets?

[dzanaga]

typeCheckingMode is set to "off"

[jakebailey]

In both of these cases, if you hover, is it correct that the signature displayed does not include the parameters the diagnostic is warning about?

[max-sixty]

FYI I see similar errors. Testing Pylance on https://github.com/pydata/xarray/tree/5377687473ecb78db085b47f4f5774eb1df93970 raises a lot of errors, many related to numpy, e.g.

            values = np.asarray(values, dtype=dtype) # <- `dtype` here

...gives...

{
	"resource": "/Users/maximilian/workspace/xarray/xarray/core/dataset.py",
	"owner": "_generated_diagnostic_collection_name_#3",
	"severity": 8,
	"message": "No parameter named \"dtype\"",
	"source": "Pylance",
	"startLineNumber": 4570,
	"startColumn": 41,
	"endLineNumber": 4570,
	"endColumn": 46
}

Also related to *args

    def transpose(self, *dims: Hashable, transpose_coords: bool = True) -> "DataArray":
    # [...]
        if dims:
            dims = tuple(utils.infix_dims(dims, self.dims))
        variable = self.variable.transpose(*dims) # <- `dims` here

...gives...

{
	"resource": "/Users/maximilian/workspace/xarray/xarray/core/dataarray.py",
	"owner": "_generated_diagnostic_collection_name_#3",
	"severity": 8,
	"message": "\"Hashable\" is not iterable\n  \"__iter__\" method not defined",
	"source": "Pylance",
	"startLineNumber": 2002,
	"startColumn": 51,
	"endLineNumber": 2002,
	"endColumn": 55
}

And it seems microsoft/python-language-server#1732 causes a total of 57 (!) errors in dataarray.py, because str as a type seems to be mangled. mypy does handle this correctly.

I expect these will reproduce by pulling the repo, but let me know if I can be helpful with logs etc.

And thanks again for this and all of Microsoft's work on python dev tools — both open and closed source — greatly valued & appreciated & excited to see what's next!

[jakebailey]

@max-sixty I'd appreciate a screenshot or two of the hovers on the functions with this message, just to see what signature we are inferring. That'd likely be the quickest way to narrow it down.

There are two things:

• This message is being reported unconditionally, but might be better suited for the "general type issues" bucket.
• The type being used may be unintentionally missing the parameter.

And it seems microsoft/python-language-server#1732 causes a total of 57 (!) errors in dataarray.py, because str as a type seems to be mangled. mypy does handle this correctly.

This seems like a separate issue; are you saying that str isn't working as a type in hints?

[jakebailey]

Numpy in particular is tricky because we need stubs to make it work, due to so much of the code being compiled. Thankfully they merged their stubs directly into their codebase (!!) which I believe will improve things greatly when released.

[dzanaga]

@jakebailey when I hover I don't actually see the signature. This is what I see:

For np.errstate if I am typing then I see the signature:

For ipywidgets only this:

Is there a way like # NOQA to ignore these warnings?

[max-sixty]

This seems like a separate issue; are you saying that str isn't working as a type in hints?

It's a fairly specific case with that file, and us using str as a value at the bottom of the file. I just put some more detail on the linked issue. Let me know if that's unclear at all. With Microsoft it caused a single error; with 'Pylanceit mangles anything withstrtype.mypy` does handle it correctly, though.

[jakebailey]

Thanks for the screenshots, this would confirm that the signature we find does not contain those things. Feasibly we can hide those messages (by sticking them into the "general type issues" category which is disabled in "off" mode), but there's a tradeoff as that'd prevent any other helpful messages where the signature actually is correct and you want to know the call is wrong. The best thing would be to get these signatures correct.

Is there a way like # NOQA to ignore these warnings?

Yes, you can use # type: ignore.

[max-sixty]

Screenshots:

[jakebailey]

@max-sixty

I'd appreciate another issue specifically for that str case. I believe the intention is to declare a class variable named str, and there may be another way to construct that line to help us understand it (but I don't want to clutter this issue about the diagnostic for an unknown param).

[jakebailey]

@max-sixty Sorry, I should have been more clear, it's the functions themselves I want to see, for the signatures.

[max-sixty]

I'd also be fine with disabling numpy until their stubs are up to date! False negatives are way better than false positives, particularly in a shared project where it's difficult to add annotations.

[max-sixty]

This is the signature of the transpose of self.variable.transpose:

Is that what you were hoping for? Lmk anything else that would be helpful

[jakebailey]

I think there are multiple issues being stated here. I was interested in the signature determined for np.asarray, which I believe is similar to the original issue with "No parameter named ...".

The dims issue is a third thing (separate again), as it's saying that you can't unpack Hashable into a *args parameter, which is true from a type checking point of view. If you believe that message to be wrong, I'd file a separate issue for that one as well, especially if you have the type checking mode set to "off".

[jakebailey]

This issue has been fixed in version 2020.7.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#202070-9-july-2020