On Fri, 27 Jan 2012 16:10:51 -0500 Barry Warsaw <ba...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com