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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4