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

[Guido van Rossum]

On Tue, Aug 30, 2011 at 8:23 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> alex23 writes:
>  > On Aug 30, 2:20 pm, Matt Joiner <anacro... at gmail.com> wrote:
>  > > Why can't a special tag/section be added in PyPi to indicate that a
>  > > module is being considered for inclusion in future versions of Python,
>  > > after all, we're all friends here.
>  >
>  > +1
>  >
>  > There was talk of making the standard library standalone. I think
>  > having a similar metapackage for experimental modules would be a more
>  > elegant way of achieving this.
>
> "Although practicality beats purity."
>
> As already mentioned several times in this thread, PyPI, Bitbucket,
> and hg.python.org sandboxes as-is provide a plenty good technical
> solution for distribution of experimental code which is almost certain
> to be included in the core distribution at some point, but currently
> the API bikeshed is being painted (well, it will be if we can only
> come to consensus on color!)
>
> The problem to be solved is on the other side of the network
> connection, internal to the *using organizations*.  Some of them have
> much stricter rules for adding new "approved" packages than for
> upgrading existing ones.  In that case, developers "inside" get much
> freer access to "official experimental" modules, and can participate
> in development (including objecting to API changes they consider
> gratuitous :-) in a way that is hard for them to justify if *before*
> dealing with any API changes they have to run an internal obstacle
> course just to be allowed to use the code.
>
> As I understand Guido's position, "experimental" is a non-starter
> unless it can be expected to significantly increase beta tests of such
> modules by developers inside organizations that strictly control their
> internal code libraries.  This requires that the "experimental"
> modules be distributed with the interpreter.  Of course, if the stdlib
> was separated out, and the current stdlib simply bundled with the
> interpreter at distribution time, the experimental package could be
> given the same treatment.  But the stdlib hasn't been done yet, and I
> don't think something labelled "experimental" would have the same
> credibility with IT Security/QA as the rest of core Python.
>
> This last might kill the whole idea, as QA might take the position
> that "yes, you're just upgrading Python 2.7 from 2.7.4 to 2.7.5, but
> we have no idea what might be in experimental, so you're going to have
> to make a separate request for that."  (I have never worked in such an
> organization so I don't know if that's a realistic worry or not.)

I wasn't actually proposing to add to (or even change the API of
modules in) the experimental package during such micro-version
updates.

TBH the best use case I can think of would actually be the ipaddr
package, which is somewhat controversial but not overly so, and seems
to lack a push to ever get it accepted. Putting it in experimental for
3.3 would let us distribute it with Python without committing 100% to
the solution it offers over its nearest competitor. However the
downside is that that's a very long wait, still provides a pretty
strong bias (unless we were to include both competing packages), and
still doesn't look like it might get enough beta testing, unless the
uptake of 3.3 is huge. So maybe we should just count PyPI downloads
and decide that way. "50,000,000 Elvis fans can't be wrong." (An
interesting meme by itself. :-)

--Guido van Rossum (python.org/~guido)