Add type stubs - #1259
Conversation
…o types-runtime-monkeytype
…o types-runtime-monkeytype
…o types-runtime-monkeytype
|
|
||
|
|
||
| def eval_feature_expression( | ||
| feature: Dict[str, Union[Dict[str, Union[str, List[List[List[float]]]]], str, Dict[str, Optional[Union[float, str, int]]]]], |
There was a problem hiding this comment.
For complex combinations of basic types, it's probably useful to introduce names for (sub)expressions.
I like the style that the httpx library uses:
https://github.com/encode/httpx/blob/master/httpx/_client.py#L1111
|
|
||
| def parse_time( | ||
| text: str | ||
| ) -> Union[Tuple[int, int, int, int, int, int, int, float], Tuple[int, int, int, int, int, int, int, None], Tuple[int, int, int, int, int, int, int, int]]: ... |
There was a problem hiding this comment.
This would also benefit from at least an alias.
|
@StefanBrand thank you for explaining the approach! I had not heard about MonkeyType. Did adding type stubs find any Fiona bugs? It will be a while before I can give my full attention to a review of this. The Fiona 1.9.4 release and some wheel building updates are higher priority for me, as are the next Rasterio release and some Shapely project governance work. |
|
@sgillies Under my impression the type stubs derived from the tests by MonkeyType are still quite broad. We would now have to make the types stricter here and there to catch bugs if there are any. My approach would be to more correctly represent the |
GDALVersion in _env
5 participants
Ref #1125
pyproject.tomlThe type stubs still contain many
Anys. Now we would really like to gather feedback to make the type annotations stricter, especially around the important places: