This avoids mypy complaining that we need to provide a generic
argument to Popen, which we cannot acctually do as the implementation
of Popen does not inherit from typing.Generic.
No fixes yet, this just gets the config in place.
Note: I'm assuming that we'll pick up a change to parso such that
it exposes its type stubs here. Otherwise we'll want to tweak the
imports config to ignore those errors.
This reinstates the import check for pydoc_data for now.
Specifically I looked in the following:
- python-3.6.8-embed-amd64.zip: missing pydoc_data
- python-3.7.8-embed-amd64.zip: present
- python-3.8.5-embed-amd64.zip: present
In particular this improves support for detecting usage of various
type annotation usages and adds support for correctly parsing
type: ignore comments which contain a reason tag.
This builds on the approach taken in https://github.com/davidhalter/jedi/pull/1613
but applies it to type vars themselves so that their type var
nature is preserved when a function returns Callable[[T], T] and
the T has an upper bound.
This avoids a `KeyError` from operator_to_magic_method lookup for
this case. Jedi probably could check for `__contains__` here, however
as it doesn't do so for `in` checks I'm following that lead for now.
Fixes https://github.com/davidhalter/jedi/issues/1594.
* Add support for generic optional parameters
* Tests for passing non-optional arguments to optional parameters
* Remove now-redundant is_class_value handling
This parameter has since been removed from infer_type_vars methods,
much simplifying the code.
get_annotated_class_object is (sort-of) the inverse of execute_annotation,
so adding a get_annotated_class_object to implement execute_annotation
specifically for Tuples didn't make much sense.
The test here is a bit contrived, the actual place I found this
was in using a NewType as a type within a NamedTuple. However due
to https://github.com/davidhalter/jedi/issues/1560 that currently
also fails for other reasons. This still feels useful to fix on
its own though.
Previously tests for these were passing somewhat by accident,
however this commit's parent adds a case which showed that the
handling was missing.
Note that this also relies on the recent fix for nested tuples
which changed the `isinstance` check in `define_generics`.
Unfortunately I can't recall exactly what it was that this test
case was trying to validate, however on a second look it turns
out that it was working by accident and did not represent a valid
use of generic type vars in Python (which cannot be used completely
unbound as this was).
This removes the _infer_type_vars util in favour of a polymorphic
implementation, removing the conditional checks on the type of
the annotation instance.
While for the moment this creates some circular imports, further
refactoring to follow should be able to remove those.
This should help catch any errors in our handling of invalid cases.
While some of these produce outputs which aren't correct, what
we're checking here is that we don't _error_ while producing that
output.
Also fix a case which this showed up.
I'm not sure why I added this, though removing it doesn't seem to
casue any issues. I suspect there might be some oddness if the type
being passed in doesn't match the type expected, though them having
the same number of generic paramters isn't an expecially great way
to validate that.
This mostly works for the new tests, but doesn't work for:
- tuples (though this seems to be because they lack generic information anyway)
- nested Type[T] handling (e.g: List[Type[T]])
While these definitely _ought_ to work on Python 2.7, the annotation
support there is very limited and as Python 2 is deprecated it
doesn't seem worth it.
Peter Law