On 1/28/2012 2:10 AM, Nick Coghlan wrote: > On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote: >> Executive summary: >> >> If the promise to remove the module from __preview__ is credible (ie, >> strictly kept), then __preview__ will have a specific audience in >> those who want the stdlib candidate code and are willing to deal with >> a certain amount of instability in that code. > > People need to remember there's another half to this equation: the > core dev side. > > The reason *regex* specifically isn't in the stdlib already is largely > due to (perhaps excessive) concerns about the potential maintenance > burden. It's not a small chunk of code and we don't want to deal with > another bsddb. ... > Really, the main benefit for end users doesn't lie in __preview__ > itself: it lies in the positive effect __preview__ will have on the > long term evolution of the standard library, as it aims to turn > python-dev's inherent conservatism (which is a good thing!) into a > speed bump rather than a road block. I was -0 on this proposal, but after Nick's discussion above I'm now +1. I also think it's worth thinking about how multiprocessing would have benefited from the __preview__ process. And for people saying "just use PyPI": that tends to exclude many Windows users from trying out packages that aren't pure Python.
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