
On Tue, Jan 19, 2021 at 6:02 AM Larry Hastings <larry@hastings.org> wrote:
Oh, okay. I haven't used the static type checkers, so it's not clear to me what powers they do and don't have. It was only a minor suggestion anyway. Perhaps PEP 649 will be slightly inconvenient to people exploring their code inside IPython.
Not only IPython, but many REPLs. Especially, Jupyter notebook is the same to IPython. We can see string annotations even in CPython REPL via pydoc. ```
def func(a: "Optional[int]") -> "Optional[str]": ... ... ... help(func)
func(a: 'Optional[int]') -> 'Optional[str]' ``` Since this signature with type hints came from inspect.signature(func), all tools using inspect.signature() will be affected too. I think Sphinx autodoc will be affected, but I am not sure.
Or maybe it'd work if they gated the if statement on running in ipython?
if typing.TYPE_CHECKING or os.path.split(sys.argv[0])[1] == "ipython3": import other_mod
It is possible for heavy modules, but not possible to avoid circular imports. Additionally, there are some cases modules are not runtime importable. * Optional dependency, user may not install it. * Dummy modules having only "pyi" files. If PEP 563 becomes the default, we can provide a faster way to get the text signature without eval() annotated string. So eval() performance is not a problem here. Many type hinting use cases don't need type objects in runtime. So I think PEP 563 is better for type hinting user experience. Regards, -- Inada Naoki <songofacandy@gmail.com>