[Python-Dev] PEP 408 -- Standard library __preview__ package
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev