<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 November 2017 at 22:38, Ilya Kulakov <span dir="ltr"><<a href="mailto:kulakov.ilya@gmail.com" target="_blank">kulakov.ilya@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A very rough implementation:<br>
<br>
typing.py:<br>
<br>
    class _GenericMetaNoop(type):<br>
        def __getitem__(self, params):<br>
            return self<br>
<br>
    class _GenericNoop(metaclass=_<wbr>GenericMetaNoop)<br>
        pass<br>
<br>
    GenericStub = Generic if TYPE_CHECKING else _GenericNoop<br>
<br>
elsewhere.py:<br>
<br>
    import typing<br>
<br>
    T = typing.TypeVar('T')<br>
<br>
    class MyClass(typing.GenericStub[T])<wbr>:<br>
        pass<br>
<br></blockquote><div><br></div><div>OK, I see.</div><div><br></div><div>Note that all type checkers known to me never actually read content of typing.py (it is always heavily special cased).</div><div>Therefore, one can safely write `GenericStub = _GenericNoop`.</div><div><br></div><div>Anyway, my expectation is that going along this way (i.e. removing all runtime API apart from a necessary minimum)</div><div>will give a minor speed-up as compared to PEP 560 at the cost of a breaking change (even for small number of developers).</div><div>PEP 560 already gives overhead of 80% as compared to normal classes in worst case scenario</div><div>(empty body with a single generic base). This is actually less than for ABCs (they can give up to 120% in worst case scenario).<br></div><div></div><div><br></div><div>Moreover, performance is not a single motivation for PEP 560, there are other arguments such as metaclass conflicts which will</div><div>not be solved without the machinery proposed by the PEP.<br></div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br>
</div></div></div></div>