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

[Ethan Smith]

On Tue, Sep 12, 2017 at 8:30 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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)
>

I think this makes a lot of sense. Would a description of the package
metadata being queried suffice to be generic enough? And a guide on
packaging.python.org makes a lot of sense, thank you for the suggestion!

>
> > 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?
>

Perhaps I could be clearer in the PEP text on this. The idea is that people
can ship normal sdists (or what have you) and install those to the package
installation directory. Then the type checkers would pick up `pkg-stub`
when looking for `pkg` type information via the package API. This allows a
third party to ship just *.pyi files in a package and install it as if it
were the runtime package, but still be picked up by type checkers. This is
different than using 'shared/typehints/pythonX.Y' because that directory
cannot be queried by package resource APIs, and since no type checker
implements PEP 484's method, I thought it would be better to have
everything be unified under the same system of installing packages. So I
suppose that is a rather long, yes. :)

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170912/b08385bc/attachment-0001.html>