On Tue, Aug 30, 2011 at 8:23 PM, Stephen J. Turnbull
alex23 writes: > On Aug 30, 2:20 pm, Matt Joiner
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)