[Python-ideas] Add from __experimental__ import bla [was: Should we move to replace re with regex?]

[Guido van Rossum]

On Sun, Aug 28, 2011 at 12:50 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Aug 28, 2011 at 2:35 PM, Devin Jeanpierre
> <jeanpierreda at gmail.com> 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)