Add type stubs for JPype internal customizers #836
Conversation
Codecov Report
@@ Coverage Diff @@
## master #836 +/- ##
============================================
- Coverage 83.06% 83.05% -0.01%
Complexity 442 442
============================================
Files 142 142
Lines 11822 11822
Branches 4462 4462
============================================
- Hits 9820 9819 -1
- Misses 1249 1250 +1
Partials 753 753
Continue to review full report at Codecov.
|
|
@marsher I have no objections to stubs, but I don't understand how to properly test this particular PR. Is this safe to release with 1.2 or do we need additional time to discuss? |
Thrameos
added
the
enhancement
|
I also do not have a clue, how to test these other than "visual inspection". |
|
@michi42 - any reason to not generate the stubs for In general, is there a reason not to do inline type annotations where feasible (i.e. not in compiled extensions) now that JPype is Py3.5+? |
|
This PR was only to introduce stubs for the JPype customizers which will be used in the Java stubs generated by stubgenj. Of course it would be nice to have stubs (or inline type annotations) for the JPype python API as well, but I considered it out of scope of this PR. The main reason why I did stub files instead of inline annotations is #714 (comment) (and following) - in the future, JPype will support loading customizers from JAR files, and the internal customizers may be moved to the JAR package shipped with JPype as well. |
I just answered a question on SO on how to test the stubs. As you might expect, it is pretty noisy with these stubs, but could be a way forwards in the future. For example, just running this on one module: With the following tweaks: diff --git a/jpype/_jcollection.pyi b/jpype/_jcollection.pyi
index 7e811332..90409608 100644
--- a/jpype/_jcollection.pyi
+++ b/jpype/_jcollection.pyi
@@ -14,29 +14,29 @@ class _JCollection(Collection[E]):
def __delitem__(self, i: E) -> None: ...
- def __contains__(self, i: E) -> bool: ...
+ def __contains__(self, i: E) -> bool: ... # type: ignore[override]
class _JList(List[E]):
- @overload
+ @overload # type: ignore[override]
def __getitem__(self, ndx: int) -> E: ...
- @overload
+ @overload # type: ignore[override]
def __getitem__(self, ndx: slice) -> E: ...
- def __setitem__(self, ndx: int, v: E) -> None: ...
+ def __setitem__(self, ndx: int, v: E) -> None: ... # type: ignore[override]
- def __delitem__(self, ndx: int) -> E: ...
+ def __delitem__(self, ndx: int) -> E: ... # type: ignore[override]
def __reversed__(self) -> Generator[E, None, None]: ...
- def index(self, obj: E) -> int: ...
+ def index(self, obj: E) -> int: ... # type: ignore[override]
def count(self, obj: E) -> int: ...
- def insert(self, idx: int, obj: E) -> '_JList'[E]: ...
+ def insert(self, idx: int, obj: E) -> '_JList'[E]: ... # type: ignore[override]
- def append(self, obj: E) -> '_JList'[E]: ...
+ def append(self, obj: E) -> '_JList'[E]: ... # type: ignore[override]
def reverse(self) -> None: ...
@@ -44,9 +44,9 @@ class _JList(List[E]):
def pop(self, idx: int = ...) -> E: ...
- def __iadd__(self, obj: List[E]) -> '_JList'[E]: ...
+ def __iadd__(self, obj: List[E]) -> '_JList'[E]: ... # type: ignore[override]
- def __add__(self, obj: List[E]) -> '_JList'[E]: ...
+ def __add__(self, obj: List[E]) -> '_JList'[E]: ... # type: ignore[override]
def remove(self, obj: E) -> None: ...
@@ -62,11 +62,11 @@ class _JMap(Mapping[K, V]):
def __setitem__(self, ndx: K, v: V) -> None: ...
- def items(self) -> Set['_JMapEntry'[K, V]]: ...
+ def items(self) -> Set['_JMapEntry']: ...
def keys(self) -> Set[K]: ...
- def __contains__(self, item: V) -> bool: ...
+ def __contains__(self, item: V) -> bool: ... # type: ignore[override]
class _JSet(Set[E]):
@@ -76,7 +76,7 @@ class _JSet(Set[E]):
class _JMapEntry(Tuple[K, V]):
def __len__(self) -> int: ...
- def __getitem__(self, x: int) -> Union[K, V]: ...
+ def __getitem__(self, x: int) -> Union[K, V]: ... # type: ignore[override]
class _JIterator(Iterator[E]):I can drop the errors to a single thing for I don't know how to fix that one though - it isn't immediately clear where the issue is coming from, and some JPype digging would be needed to figure it out (I suspect one of you will look at it and instantly know the reason). Proposal: In order to avoid these stubs becoming obsolete/incorrect, we introduce CI to run the stubtest command on them to confirm that they represent reality. |
This is a first version of type stubs for the customizers that ship with JPype.
Ideally the classes should be re-organized so there is exactly one customizer python module per Java Package, but this would most certainly interfere with #828, so I didn't do it in this branch.