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
signature.asc
Description: PGP signature
_______________________________________________ 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
