[Python-ideas] stdlib upgrades

[M.-A. Lemburg]

Ian Bicking wrote:
>> IMHO, we've so far done well by issuing new Python patch level
>> releases whenever there was a problem in the stdlib (and only
>> then).
>>
>> Introducing new features by way of updates is left to
>> minor releases, which then require more testing by the
>> user.
>>
>> This additional testing is what causes many corporates to
>> not follow the Python release cycle or skip a few minor
>> releases: the work involved often just doesn't warrant the
>> advantages of the added new features.
>>
> 
> Yes, and so applications and libraries have to work around bugs instead of
> using fixed versions, generally making upgrades even more danger-prone.  In
> the case of package management, the hardest libraries to support are those
> libraries that have included a large number of fixes for installation
> problems in their setup.py.

True, but at least you know which work-arounds to remove
in case you upgrade to a new stdlib version which fixes those
problems.

Users put a lot of trust into the stdlib reliability as a single
package and are well aware of the fact that using many 3rd party
packages put them at risk due to sometimes missing interoperability
checks of those packages (which, of course, is hard for the 3rd
package authors to do, since they can hardly know what combination
a particular is using).

> Futzing around with most of the standard library right now would just add
> complexity, and applying changes that might be more aesthetic than
> functional would be a really bad choice and lead to tedious discussions.

Agreed.

> But new functionality can't usefully *just* exist in the standard library
> because basically no one is using 2.7, few people are using 3.x, and lots of
> people are using 2.5 or at best 2.6 -- so new functionality should be
> available to all those people.  Which means there *has* to be releases of
> any new functionality.  argparse was already released, and so there will be
> "argparse" out in the wild that anyone can install on any version of Python
> shadowing the existing module.  unittest improvements are being released as
> unittest2... meaning I guess that the "proper" way to use that functionality
> would be:
> 
> import sys
> if sys.version_info >= (2, 7):
>     import unittest
> else:
>     import unittest2 as unittest

True and that's how most code bases I've seen work: they start
with a 3rd party package and then revert to stdlib one once
it's integrated.

>> The situations won't get any better if we start releasing
>> partial or complete stdlib updates even more often.
> 
> That a stdlib release means potentially *any* part of the standard library
> could have been upgraded (even though it probably won't be) probably will
> throw people off.

I'm not sure about that one. Users I've worked with typically trust the
interoperability of the stdlib a lot more than that of a set of 3rd party
packages and even though there may be lots of different changes in the stdlib,
the package as a whole is assumed to be more robust and better tested than
the average set of 3prd party packages (even though this may not be
a true assumption).

> The advantage of versions on specific functionality is that you can upgrade
> just what you care about.  It's much less burdensome to test something that
> actually fixes a problem for you, and of course people do that all the time
> with non-standard libraries.

True, that's why people add work-arounds or specific fixes
for the stdlib to their setup.py ... so that they can (conditionally)
remove them again, when the next Python version is released.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 02 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                46 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/