[Python-Dev] PEP 408 -- Standard library __preview__ package

[Antoine Pitrou]

On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw <barry at python.org> wrote:
> 
> I'm -1 on this as well.  It just feels like the completely wrong way to
> stabilize an API, and I think despite the caveats that are explicit in
> __preview__, Python will just catch tons of grief from users and haters about
> API instability anyway, because from a practical standpoint, applications
> written using __preview__ APIs *will* be less stable.

Well, obviously __preview__ is not for the most conservative users. I
think the name clearly conveys the idea that you are trying out
something which is not in its definitive state, doesn't it?

> >I think a significantly healthier process (in terms of maximizing feedback
> >and getting something into it's best shape) is to let a project evolve
> >naturally on PyPi and in the ecosystem, give feedback to it from an inclusion
> >perspective, and then include it when it becomes ready on it's own
> >merits. The counter argument to this is that putting it in the stdlib gets
> >you signficantly more eyeballs (and hopefully more feedback, therefore), my
> >only response to this is: if it doesn't get eyeballs on PyPi I don't think
> >there's a great enough need to justify it in the stdlib.
> 
> I agree with everything Alex said here.

The idea that being on PyPI is sufficient is nice but flawed (the
IPaddr example). PyPI doesn't guarantee any visibility (how many
packages are there?). Furthermore, having users is not a guarantee that
the API is appropriate, either; it just means that the API is
appropriate for *some* users.

On the other hand, __preview__ would clearly signal that something is
on the verge of being frozen as an official stdlib API, and would
prompt people to actively try it.

Regards

Antoine.