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 master and 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.txt or 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 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 GenericPath test failing after typeshed upgrade #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]) -> str
HoverTests.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’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 typing since typing source 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 #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/

Navigation Menu

Repository navigation

Update typeshed to a more recent version #1371

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update typeshed to a more recent version #1371

Description

Activity

jakebailey commented on Jul 25, 2019

jakebailey commented on Jul 25, 2019

jakebailey commented on Jul 25, 2019

jakebailey commented on Sep 10, 2019

jakebailey commented on Oct 11, 2019

jakebailey commented on Oct 14, 2019

Aeron commented on Apr 6, 2020

MikhailArkhipov commented on Apr 6, 2020

Aeron commented on Apr 10, 2020

MikhailArkhipov commented on Apr 10, 2020

jakebailey commented on Jun 30, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions