n Sat, Jan 28, 2012 at 3:26 AM, Alex <alex.gay...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
