python-language-server icon indicating copy to clipboard operation
python-language-server copied to clipboard

Update typeshed to a more recent version

Open jakebailey opened this issue 6 years ago • 11 comments

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:

  1. NEW: Grab the latest master hash from the repo.
  2. Download the zip archive for that hash (instead of grabbing master and then asking for the version).
  3. Extract the archive.
  4. NEW: Mark the directory and its contents as read-only.
  5. NEW: Write the hash out to a file, like version.txt or something.

jakebailey avatar Jul 23 '19 23:07 jakebailey

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[...]].

jakebailey avatar Jul 25 '19 22:07 jakebailey

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.

jakebailey avatar Jul 25 '19 22:07 jakebailey

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).

jakebailey avatar Jul 25 '19 22:07 jakebailey

Marking as a 3.8, since there's going to be new stuff.

jakebailey avatar Sep 10 '19 20:09 jakebailey

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]) -> 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.

jakebailey avatar Oct 11 '19 22:10 jakebailey

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.

jakebailey avatar Oct 14 '19 21:10 jakebailey

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.

Aeron avatar Apr 06 '20 16:04 Aeron

Typeshed won't help with typing since typing source is not parsed and is rather specialized in code.

MikhailArkhipov avatar Apr 06 '20 16:04 MikhailArkhipov

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.

Aeron avatar Apr 10 '20 04:04 Aeron

There is a catch-all https://github.com/microsoft/python-language-server/issues/535 for typing, feel free to comment.

MikhailArkhipov avatar Apr 10 '20 04:04 MikhailArkhipov

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/

jakebailey avatar Jun 30 '20 22:06 jakebailey