<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 12:44 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Oct 26, 2017 at 3:42 PM, Ethan Smith <<a href="mailto:ethan@ethanhs.me" target="_blank">ethan@ethanhs.me</a>> wrote:<br>
> However, the stubs may be put in a sub-folder<br>
> of the Python sources, with the same name the ``*.py`` files are in. For<br>
> example, the ``flyingcircus`` package would have its stubs in the folder<br>
> ``flyingcircus/flyingcircus/``<wbr>. This path is chosen so that if stubs are<br>
> not found in ``flyingcircus/`` the type checker may treat the subdirectory as<br>
> a normal package.<br>
<br>
</span>I admit that I find this aesthetically unpleasant. Wouldn't something<br>
like __typestubs__/ be a more Pythonic name? (And also avoid potential<br>
name clashes, e.g. my async_generator package has a top-level export<br>
called async_generator; normally you do 'from async_generator import<br>
async_generator'. I think that might cause problems if I created an<br>
async_generator/async_generato<wbr>r/ directory, especially post-PEP 420.)<br></blockquote><div><br></div><div>I agree, this is unpleasant, I am now of the thought that if maintainers do not wish to ship stubs alongside their Python code, they should just create separate stub-only packages. I don't think there is a particular need to special case this for minor convenience.<br></div><div><br></div><div><snip> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Type Checker Module Resolution Order<br>
> ------------------------------<wbr>------<br>
><br>
> The following is the order that type checkers supporting this PEP should<br>
> resolve modules containing type information:<br>
><br>
> 1. User code - the files the type checker is running on.<br>
><br>
> 2. Stubs or Python source manually put in the beginning of the path. Type<br>
>    checkers should provide this to allow the user complete control of which<br>
>    stubs to use, and patch broken stubs/inline types from packages.<br>
><br>
> 3. Third party stub packages - these packages can supersede the installed<br>
>    untyped packages. They can be found at ``pkg-stubs`` for package ``pkg``,<br>
>    however it is encouraged to check the package's metadata using packaging<br>
>    query APIs such as ``pkg_resources`` to assure that the package is meant<br>
>    for type checking, and is compatible with the installed version.<br>
<br>
</span>Am I right that this means you need to be able to map from import<br>
names to distribution names? I.e., if you see 'import foo', you need<br>
to figure out which *.dist-info directory contains metadata for the<br>
'foo' package? How do you plan to do this?<br> 
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem is that technically, import names and distribution names<br>
are totally unrelated namespaces -- for example, the '_pytest' package<br>
comes from the 'pytest' distribution, the 'pylab' package comes from<br>
'matplotlib', and 'pip install scikit-learn' gives you a package<br>
imported as 'sklearn'. Namespace packages are also challenging,<br>
because a single top-level package might actually be spread across<br>
multiple distributions.<br>
<span class="m_1800367699741208060m_-5340158043419758978HOEnZb"><font color="#888888"><br></font></span></blockquote><div> </div></div><div class="gmail_quote">This is a problem. What I now realize is that the typing metadata is needed for *packages* and not distributions. I will work on a new proposal that makes the metadata per-package. It will require a slightly more complicated proposal, but I feel that it is necessary. Thank you for realizing this issue with my proposal, I probably should have caught it earlier.<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_1800367699741208060m_-5340158043419758978HOEnZb"><font color="#888888">
-n<br>
<br>
--<br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</font></span></blockquote></div><br></div></div>