-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pylance uses its own type stubs over actually installed libraries #1197
Comments
I recently added those logs and it does look like we are sticking typeshed before
But, it's a risky change to change this ordering, lest some stubs that work stop working. |
I will note that if pyjwt is stubbed and has |
PyJWT does have |
Yes, I only suggest that as a workaround and courtesy to the typeshed project; it's a problem that we are using typeshed or our own stubs for projects that have their own. |
Incidentally, I think this is the same issue as microsoft/pyright#1764. |
Yes, almost certainly. |
This issue has been fixed in version 2021.5.3, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202153-19-may-2021 |
Yes and no... while Pylance 2021.5.3 is certainly looking in the right place:
...it's not getting the right type: Minimal demo repo: https://github.com/fluggo/pylance-test |
This highlights the problem with overriding typeshed stubs with "py.typed" type information. We find that sometimes library authors mark their library as "py.typed" when they do not provide complete type information in their library code. That's what you're seeing here with PyJwt. For details about how pylance handles "py.typed" libraries — and what it expects in terms of type information, refer to this documentation. Pyright (the type checker upon which pylance is built) contains a command-line option called
That's a pretty low type completeness score. The library should probably not be marked as "py.typed" until its type information is more complete. Any symbol that has an "unknown type" will be treated as an We're also discussing the possibility of adding an option to pyright that allows you to ignore the "py.typed" for a library, falling back on type inference to try to infer the missing type information. Refer to this issue if you're interested in the details or would like to join in on the discussion. |
If I'm understanding the documentation right, Pyright loses the plot here, at the end of api_jwt.py, when encode is aliased to a module variable? _jwt_global_obj = PyJWT()
encode = _jwt_global_obj.encode
decode_complete = _jwt_global_obj.decode_complete
decode = _jwt_global_obj.decode If so, that is... really unfortunate, as the implementor has to repeat a lot of type information just to make that simple statement work. ETA: Reading further on the rationale, I see why Pyright decided to do this. It would be different if these variables could be declared |
Even if they were declared To address this, library authors may need to add a few additional (otherwise unnecessary) type annotations. In most cases, this involves very little extra work, and it provides real benefits to consumers of that library. So my hope is that library authors won't see it as too onerous. TypeScript has things a bit easier because there are not multiple type checkers for TypeScript; everything is handled by the TypeScript compiler itself, and there's only one of those. In the Python world there are many different implementations of type checkers, linters and language servers. This diversity is good, but it can also present some challenges. |
Thank you for the background. Seems like Python still has a way to go in the typing journey, but I'd like to encourage it. I feel static checking like this is an essential tool, and Python is too cool of a language to miss out. |
I also encountered this issue with Have we reached a consensus on how to solve this problem? |
What problem are you referring to? We've removed the pyjwt stubs we had bundled, so they no longer conflict. If you mean the quality of the types, that is up to the library and is tracked in the cross-linked issue here: jpadilla/pyjwt#660 |
The |
This will probably be fixed once python/typeshed#5767 is merged; I was wrong to say that we had removed the stubs. |
Though, we should still be picking pyjwt's own types, as it's py.typed (why this issue is closed), so maybe not. Hard to say without some trace logs to show what we are analyzing. |
Environment data
Expected behaviour
Pylance should search the venv libraries to see if they support types before searching its own bundled type stubs.
Actual behaviour
Pylance, when operating on PyJWT 2.0.1, tries to flag that the return type of jwt.encode is bytes, not str:
...which would be helpful, except that by all rights, that definition does not exist. PyJWT's own code says:
Pylance seems to be pulling in a different definition for the types than the ones defined in the installed library.
Logs
Pylance sets its search paths like so:
Pylance parses its own type stub:
and the installed one:
...but seems to prefer its own.
The text was updated successfully, but these errors were encountered: