[Python-ideas] PEP 561 v2 - Packaging Static Type Information

[Nick Coghlan]

On 13 September 2017 at 09:43, Ethan Smith <ethan at ethanhs.me> wrote:
> The two major parts of this specification are the packaging specifications
> and the resolution order for resolving module type information. This spec
> is meant to replace the ``shared/typehints/pythonX.Y/`` spec of PEP 484
> [2]_.

There are a lot of packaging tools in use other than distutils, so I
don't think the distutils update proposal belongs in the PEP. Rather,
the PEP should focus on defining how type analysers should search for
typing information, and then updating packaging tools to help with
that can be treated as separate RFEs for each of the publishing tools
that people use (perhaps with a related task-oriented guide on
packaging.python.org)

> Type Checker Module Resolution Order
> ------------------------------------
>
> The following is the order that type checkers supporting this PEP should
> resolve modules containing type information:
>
> 1. User code - the files the type checker is running on.
>
> 2. Stubs or Python source manually put in the beginning of the path. Type
>    checkers should provide this to allow the user complete control of which
>    stubs to use, and patch broken stubs/inline types from packages.
>
> 3. Third party stub packages - these packages can supersede the installed
>    untyped packages. They can be found at ``pkg-stubs`` for package ``pkg``,
>    however it is encouraged to check their metadata to confirm that they opt
>    into type checking via the ``typed`` keyword.

> 4. Inline packages - finally, if there is nothing overriding the installed
>    package, and it opts into type checking.
>
> 5. Typeshed (if used) - Provides the stdlib types and several third party
>    libraries

I'm not clear on how this actually differs from the existing search
protocol in PEP 484, since step 3 is exactly what the
'shared/typehints/pythonX.Y' directory is intended to cover.

Is it just a matter allowing the use of "<name>-stubs" as the typehint
installation directory, since installing under a different package
name is easier to manage using existing publishing tools than
installing to a different target directory?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia