On Sun, Aug 28, 2011 at 12:50 AM, Nick Coghlan
On Sun, Aug 28, 2011 at 2:35 PM, Devin Jeanpierre
wrote: Keeping it third-party means many people will be reluctant to add it as a dependency to any code they put out.
I'd spin this as a good thing: the code is, after all, experimental.
Indeed. And using a DVCS means it is easier these days for people to get hold of experimental code (e.g. anyone that wants to play with the yield from expression can grab it from bitbucket and build it locally: https://bitbucket.org/ncoghlan/cpython_sandbox#pep380)
Documenting that packages are up for standard lib inclusion is good (specifically regex right now, but likely a couple of others before 3.3), but I don't think that means actually *shipping* them in the stdlib is a good idea.
A meta-package on PyPI for "stdlib-experimental" might be a way to let people grab candidates all at the same time if it's considered worthwhile, but the stdlib itself should only get stuff we plan to keep around.
I still see a huge difference between something in PyPI and something marked as experimental in the stdlib. Something in PyPI may or may not be promoted to stdlib status, but realistically that rarely happens (I think the last time it happened it was a JSON thing?). Something marked as experimental in the stdlib has a much higher likelihood to be promoted to regular stdlib status -- in fact that's the most likely outcome. The main difference between experimental and regular status in the stdlib is that for experimental modules we reserve the right to make incompatible changes in subsequent versions (possibly even in bugfix releases, although that's worth a separate discussion). An experimental feature in the stdlib also signals a certain commitment from the core developers. We shouldn't use experimental as a dumping ground for random stuff; that's what PyPI is for. We should use experimental within the context of the stdlib. Another thing to keep in mind is that not everybody has the same attitude towards installing 3rd party dependencies from PyPI. E.g. at Google, that requires someone to import the 3rd party library into our own code repo first, and that in turn requires a (light-weight) review. The net effect is that a Googler who happens to be the first to want to use a certain 3rd party package has to do a lot of work; it's *not* just a matter of downloading and installing the package. I imagine it's the same within many other organizations -- some better, some worse. (I was going to write something about many package developers being reluctant to require dependencies on other packages, but that's a pretty weak argument, since depending on an experimental stdlib package would limit them to a specific Python version, or dynamic presence-checking which isn't much better than having optional PyPI dependencies.) The power of "batteries included" is still with us, and experimental batteries are still batteries! -- --Guido van Rossum (python.org/~guido)