<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 April 2018 at 09:59, Ethan Smith <span dir="ltr"><<a href="mailto:ethan@ethanhs.me" target="_blank">ethan@ethanhs.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>I've updated PEP 561 to clarify that any installed stub package should supersede an installed inline package. In other words if there is:</div><div><br></div><div>
/global/site-packages/pkg/

<br></div><div>/user/site-packages/pkg-stubs/</div><div><br></div><div>Even if pkg in the global site packages is found first and marks that it supports types, the stub package should supersede it.</div><div></div><div><br></div><div>I also point to mypy's docs on its implementation of the PEP (which can be read about here: <a href="https://mypy.readthedocs.io/en/latest/installed_packages.html" target="_blank">https://mypy.readthedocs.io/<wbr>en/latest/installed_packages.<wbr>html</a>). The implementation has been merged into master and will be available in the 0.590 release.<br></div><div><br></div></div></blockquote><div><br></div><div>This clarification totally makes sense for me. I could easily imagine a scenario where are third party provides more advanced/precise/detailed types for a package that already supports typing. Also thanks for writing the implementation, hopefully, this PEP will be accepted soon and it will solve one of the major problems in typing ecosystem.</div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div> </div></div></div></div>