Ivan Levkivskyi
Ivan Levkivskyi
We could support at least Google style and Numpydoc
We should support translating type comments like this: ```python x, y = ... # type: Tuple[int, int] ``` Note this may be not totally trivial in r.h.s. is a single...
Add support for transforming ```python x: int y: str = 'hi' ``` to ```python x = None # type: int y = 'hi' # type: str ``` etc.
Potentially, we can translate this: ```python for i, j in foo(bar): # type: (int, int) ... ``` to something like this ```python i: int j: int for i, j in...
If ``typing_inspect`` will become part of ``typing`` in the future (or some parts of it), then we can merge it with the ``typing`` stub.
The approximate idea is to do something like this: ```python def reveal_type(obj): print(get_generic_type(obj)) return obj ``` Then in the stub for ``typing_inspect`` we can write something like: ``` from builtins...
This discussion was started in #8, but now that issue is mostly about `__match__()` API. So I would like to open a separate issue about providing some utilities/helpers for pattern...
Probably not very important, but while reading code it looks like a negative match may be useful. For example, when people write something like `not isisnstance(x, Foo) or x.y !=...
I propose to add a `@typing.sealed` class decorator that would do nothing at runtime, but indicate to static type checkers that all subclases must be defined in the same module....
From my understanding of #8 the current proposal is that there is no `object.__match__()` so that by default trying to match against `Foo()` raises an error. In my draft notes...