[Python-Dev] Intent to accept PEP 561 -- Distributing and Packaging Type Information
levkivskyi at gmail.com
Wed Jun 27 19:18:30 EDT 2018
Well done! I think PEP 561 will significantly simplify typing third party
On 28 June 2018 at 00:11, Guido van Rossum <guido at python.org> wrote:
> Well, with that, I am hereby accepting PEP 561.
> Ethan has done a tremendous job writing this PEP and implementing it, and
> I am sure that package and stub authors will be very glad to hear that
> there are now officially supported ways other than typeshed to distribute
> type annotations.
> Congrats Ethan!
> On Mon, Jun 25, 2018 at 12:15 PM Guido van Rossum <guido at python.org>
>> OK, last call! I'll accept the current draft tomorrow unless someone
>> pushes back.
>> On Fri, Jun 22, 2018 at 8:37 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 23 June 2018 at 01:16, Guido van Rossum <guido at python.org> wrote:
>>> > That sounds like you're supporting PEP 561 as is, right?
>>> Aye, I'm personally fine with it - we do need to do something about
>>> automatically reserving the derived names on PyPI, but I don't think
>>> that's a blocker for the initial PEP acceptance (instead, it will go
>>> the other way: PEP acceptance will drive Warehouse getting updated to
>>> handle the convention already being adopted by the client tools).
>>> > Excuse my
>>> > ignorance, but where are API testing stub interfaces described or used?
>>> They're not - it's just the context for Donald referring to "stubs" as
>>> being a general technical term with other meanings beyond the "type
>>> hinting stub file" one.
>>> As such, there's three parts to explaining why we're not worried about
>>> the terminology clash:
>>> - Ethan searched for projects called "*-stubs" or "*_stubs" and didn't
>>> find any, so the practical impact of any terminology clash will be low
>>> - there isn't an established need to automatically find testing stub
>>> libraries based on an existing project name the way there is for type
>>> - even if such a need did arise in the future, the "py.typed" marker
>>> file and the different file extension for stub files within a package
>>> still gives us an enormous amount of design flexibility
>>> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
>> --Guido van Rossum (python.org/~guido)
> --Guido van Rossum (python.org/~guido)
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev