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

Guido van Rossum guido at python.org
Thu Sep 1 21:57:47 CEST 2011


On Thu, Sep 1, 2011 at 11:34 AM, Barry Warsaw <barry at python.org> wrote:
> 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. ;)

It still sounds like they are (nearly) orthogonal though. Even if we
had such a feature we'd still want to put ipaddr 0.5 into
experimental, but most other new stdlib modules would not have to go
there. And even if we didn't have such a feature, I'd still consider
putting things in experimental, and just telling people to deal with
it. Especially since we *don't* have the feature. :-)

>>> 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!

That's what I'm talking about! :-)

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



More information about the Python-ideas mailing list