[Python-ideas] multi-version libraries (was Re: Add from __experimental__ import bla)

On Aug 31, 2011, at 09:31 AM, Guido van Rossum wrote:

On Wed, Aug 31, 2011 at 8:19 AM, Barry Warsaw wrote:

...

On Aug 30, 2011, at 08:53 PM, Guido van Rossum wrote:

...

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. :-)

I think an experimental namespace is actually attacking the wrong problem, or maybe the right problem in the wrong way. ;)

I'd much prefer to see some brainstorming on multi-version support, which is something that Robert Collins is always bugging me about.  Something like pkg_resource's require() function seems like a good place to start.

It's a great idea to brainstorm about, just not in this thread. I see the two issues completely orthogonal.

It seems related though. It seems like the primary use case for experimental, especially in reference to the ipaddr module, is "we're including this battery, but it's shape might change, so don't count on it fitting into your socket next release". With multi-version libraries, we don't have to be so wishy-washy. We could say "here's version 0.5 of ipaddr" and the next release could safely include both that version and a stable, completely redesigned API of ipaddr 1.0. The two could co-exist (for a while), supporting both the legacy API, and the new whizzy one we actually like. ;)

...

If we had this built-in, then including ipaddr in the stdlib as it currently stands would be a no-brainer, even with a suboptimal API.  It would get lots of testing, and a completely different API could be designed for Python 3.4 without break packages that relied on the old API.  Python's deprecation policy could be adjusted to include diminishing support for older versions of a module in the stdlib, and we'd avoid ugliness like unittest2 and such.

You sound like you have a solution for using multiple versions of an API in the same program. Do you? Then out with it! Otherwise, no, it wouldn't be a no-brainer.

I wish I did! -Barry