n Sat, Jan 28, 2012 at 3:26 AM, Alex <alex.gaynor at gmail.com> wrote: > 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. And what about a project like regex, which *has* the eyeballs on PyPI, but the core devs aren't confident enough of its maintainability yet to be happy about adding it directly to the stdlib with full backwards compatibility guarantees? The easy answer for us in that context is to just not add it (i.e. the status quo), which isn't a healthy outcome for the overall language ecosystem. Really, regex is the *reason* this PEP exists: we *know* we need to either replace or seriously enhance "re" (since its Unicode handling isn't up to scratch), but we're only *pretty sure* adding "regex" to the stdlib is the right answer. Adding "__preview__.regex" instead gives us a chance to back out if we uncover serious problems (e.g. with the cross-platform support). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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