Our vendored copy of typeshed is very old and should get updated. Other than general fixes and improvements, there have been some additions/tweaks to the third_party directory which would likely benefit users of libraries like flask or requests.
Additionally, our typeshed updating script should write out the git hash of what version we have so we can keep track of what is checked out.
The script could be changed to do:
master and then asking for the version).version.txt or something.I tried doing the above and running the test suite. All of our tests pass, except:
Source: TypeshedTests.cs line: 42
Duration: 11 sec
Message:
Expected Type.Name to be
"BaseException" with a length of 13, but
"Union[Tuple[Type[BaseException], BaseException, TracebackType], Tuple[]]" has a length of 72.
Stack Trace:
at LateBoundTestFramework.Throw(String message) in LateBoundTestFramework.cs line: 16
at AssertionScope.FailWith(String message, Object[] args) in AssertionScope.cs line: 225
at StringEqualityValidator.ValidateAgainstLengthDifferences() in StringEqualityValidator.cs line: 30
at StringValidator.Validate() in StringValidator.cs line: 41
at StringAssertions.Be(String expected, String because, Object[] becauseArgs) in StringAssertions.cs line: 41
at MemberAssertions.HaveType(String typeName, String because, Object[] reasonArgs) in MemberAssertions.cs line: 146
at VariableAssertionsExtensions.OfType[TAssertion](AndWhichConstraint`2 andWhichConstraint, String typeName, String because, Object[] reasonArgs) in VariableAssertionsExtensions.cs line: 33
at TypeshedTests.TypeShedSysExcInfo() in TypeshedTests.cs line: 49
Open additional output for this result
This is because typeshed now says:
_ExcInfo = Tuple[Type[BaseException], BaseException, TracebackType]
_OptExcInfo = Union[_ExcInfo, Tuple[None, None, None]]
def exc_info() -> _OptExcInfo: ...
And our unpacking can't deal with Union[Tuple[...], Tuple[...]].
Since typeshed has started using __ prefixes to indicate positional-only parameters (as the stub syntax is fixed to an older Python 3 syntax), we may need to consider some pre-processing to what we vendor to avoid displaying the __ parameters coming from these stubs. See also the related #1389.
Also, we'll need to add support (or at least declare) Protocol. For our sake, it should be sufficient to declare this as an empty class (since all subclasses of Protocol add the methods).
Marking as a 3.8, since there's going to be new stuff.
Current blockers to upgrade, strictly from the test front:
GenericsTest.GenericPath - Fails because PurePath as the bound to _T was changed from string form to a forward reference (not within PEP 484 but apparently allowed). We try to fetch the value, see that it hasn't been evaluated, try to evaluate it, then since it's happening for _T's assignment, it can't find _T, and that fails. This I opened as #1654. I can choose to not evaluate classes when they're referenced by name in stub, but that breaks GenericFunctionArguments, as it seems to require some eval to propagate a type.HoverTests.FromOsPath - Not entirely sure why this passed before. Fails because we used to show join(path: str, *paths: str) -> str (which is nice looking), but we now resolve it to the "real" Union[Text, _PathLike[Text]]. _PathLike is from builtins import _PathLike, but we don't define _PathLike, so that's Unknown, which is trimmed from the union, netting: join(path: Union[str], *paths: Union[str]) -> strHoverTests.HoverSpanCheck - The signature of datetime.now was changed to be more esoteric, i.e. def now(cls: Type[_S], tz: Optional[_tzinfo] = ...) -> _S: .... We cannot handle cls: Type[_S] or self: _S, so using this construct doesn't net good results. Also, even though I run the test with 3.8, it's picking up the two overloads for < 3.8. No idea.I think we're not going to be able to just upgrade typeshed without some major type system changes. Instead, we'll wait for 3.8 to be "done" upstream, then fork it with some simple transformations to make things usable for our analysis (replacement of some of the above things). This will end up being faster for getting new 3.8 stuff into our stubs than fixing the analysis.
Is there any progress or even plans on this? It鈥檚 frustrating to use suggestions (for Python 3.8 code) which can鈥檛 suggest you a dozen of things, especially for typing module, or to see tips for function arguments with Unknown instead of proper typing.Hashable, for example.
Typeshed won't help with typing since typing source is not parsed and is rather specialized in code.
Typeshed won't help with
typingsincetypingsource is not parsed and is rather specialized in code.
Should I create a separate issue for typing module related problems particularly then, or those are already well known? Didn鈥檛 find anything similar previously, maybe I overlooked something.
There is a catch-all https://github.com/microsoft/python-language-server/issues/535 for typing, feel free to comment.
FWIW the new LS we released today has full typing support (and a new typeshed): https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/
Most helpful comment
FWIW the new LS we released today has full typing support (and a new typeshed): https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/