Update typeshed to a more recent version
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:
- NEW: Grab the latest master hash from the repo.
- Download the zip archive for that hash (instead of grabbing
masterand then asking for the version). - Extract the archive.
- NEW: Mark the directory and its contents as read-only.
- NEW: Write the hash out to a file, like
version.txtor something.
I tried doing the above and running the test suite. All of our tests pass, except:
TypeShedSysExcInfo
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 becausePurePathas the bound to_Twas 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 breaksGenericFunctionArguments, 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 showjoin(path: str, *paths: str) -> str(which is nice looking), but we now resolve it to the "real"Union[Text, _PathLike[Text]]._PathLikeisfrom 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 ofdatetime.nowwas changed to be more esoteric, i.e.def now(cls: Type[_S], tz: Optional[_tzinfo] = ...) -> _S: .... We cannot handlecls: Type[_S]orself: _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’s frustrating to use suggestions (for Python 3.8 code) which can’t 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’t 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/