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

Paul Moore p.f.moore at gmail.com
Fri Jan 27 23:02:00 CET 2012

On 27 January 2012 21:48, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 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?

Agreed. But that in turn implies to me that __preview__.foo should not
be maintained as an alias for foo once it gets "promoted". Firstly,
because if you're not comfortable with changing your code to make the
simple change to remove the __preview__ prefix in the import, then how
could you be comfortable with using a module with no compatibility
guarantee anyway?

(BTW, I assume that the normal incantation would actually be "from
__preview__ import foo", as that limits the module name change to the
import statement).

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

Agreed entirely. We need a way to signal somehow that a module is
being seriously considered for stdlib inclusion. That *would* result
in more uptake, and hence more testing and feedback. As an example, I
would definitely try out MRAB's regex module if it were in
__preview__, but even though I keep meaning to, I've never actually
got round to bothering to download from PyPI - I end up just using the
stdlib re for my one-off scripts.

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

Precisely. It's in effect a "last call for feedback", and people
should view it that way, in my opinion.


More information about the Python-Dev mailing list