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

[Barry Warsaw]

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

>On Wed, Aug 31, 2011 at 8:19 AM, Barry Warsaw <barry-+ZN9ApsXKcEdnm+yROfE0A at public.gmane.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110901/c103edaf/attachment.pgp>