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

Barry Warsaw barry at python.org
Fri Jan 27 22:10:51 CET 2012


On Jan 27, 2012, at 05:26 PM, Alex wrote:

>I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
>instead of it's final destination directly because it needs feedback/possibly
>changes. However, given the release cycle of the stdlib (~18 months), any
>feedback it gets can't be seen by actual users until it's too
>late. Essentially you can only get one round of stdlib.

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.

It also won't improve the situation for prospective library developers because
they're locked into Python's development cycle anyway.  I also think the
benefit to users is a false one since it will be much harder to write
applications that are portable across Python releases.

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

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120127/72c35059/attachment.pgp>


More information about the Python-Dev mailing list