[Python-ideas] Moving typing out of the stdlib in Python 3.7?

[Stéfane Fermigier]

I use typing quite systematically nowadays, even for projects that don't
use mypy (for historical reasons: bringing an older code base to zero mypy
issues can be quite time-consuming).

For instance, adding typing annotation can help autocompletion under
PyCharm (and hopefully other IDEs).

With these annotations, PyCharm is also able to signal typing issues either
directly in the editor, or when running a code check.

I'm quite OK with removing the typing module from the stdlib as it can
easily be added to my projects dependencies, and I can definitively
understand the benefits of a faster release cycle, but I'm worried that
this could hinder adoption of these practices by certain people.

  S.

On Fri, Nov 3, 2017 at 3:35 PM, Guido van Rossum <guido at python.org> wrote:

> [A copy from https://github.com/python/typing/issues/495 to get more
> people's attention to this issue.]
>
> I'm wondering if we should remove typing from the stdlib. Now's the time
> to think about this, as the feature freeze for 3.7 is about 12 weeks away.
>
> Cons:
>
>    - People have to depend on a PyPI package to use typing (but they do
>    anyway for typing_extensions)
>    - It's a backward incompatibility for users of Python 3.5 and 3.6 (but
>    the typing module was always provisional)
>
> Pros:
>
>    - The typing module can evolve much faster outside the stdlib
>    - We could get rid of typing_extensions (and maybe even mypy_extensions
>    )
>
> If we don't do this I worry that we're entering a period where many new
> typesystem features end up in typing_extensions and users will be
> confused about which items are in typing and which in typing_extensions
> (not to mention mypy_extensions). Anything new to be added to typing
> (e.g. Const, Final, Literal, or changing ABCs to Protocols) would have to
> be added to typing_extensions instead, and users would be confused about
> which features exist in which module. Moving typing out of the stdlib can
> make things potentially simpler, at the cost of an extra pip install (but
> they'll need one anyway for mypy).
>
> Thoughts?
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free&OSS Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171103/f98d4b8f/attachment.html>