On Wed, Jun 2, 2010 at 5:13 AM, M.-A. Lemburg <span dir="ltr"><<a href="mailto:mal@egenix.com">mal@egenix.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

While I played with this idea a long time ago as well, I have<br>
since found that it causes more trouble than it's worth.<br>
<br>
Apart from having the user to maintain at least two different<br>
versioned packages (Python and (part of) the stdlib), it also<br>
causes problems if you use this Python installation for more<br>
than one project: it's easily possible to have project A require<br>
version 2 or a stdlib module and project B version 3 of that<br>
same module.<br></blockquote><div><br>This exists for normal libraries currently, and using virtualenv I've found it to be manageable.  It does require process separation (and sys.path separation) in some cases.<br><br>

I agree that global upgrades  are dangerous.  distutils2/pip may be different because projects don't generally get used except when managing a project, and very few projects will require any particular version of these libraries.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If you then load both projects in an application, you end up<br>
either with a broken project A or B (depending on whether you have<br>
version 2 or 3 of that stdlib module installed), or you allow<br>
loading multiple versions of the same module, in which case you<br>
will likely break you application, since it will find multiple<br>
class implementations (and objects) for the the same instances.<br>
<br>
Things like exception catching, pickling (and esp. unpickling),<br>
security checks based on classes, interface adapters and even<br>
simply isinstance() checks would then fail in various hard to<br>
reproduce ways.<br></blockquote><div><br>Yes, multiple versions of a library loaded at the same time is not a good idea.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


IMHO, we've so far done well by issuing new Python patch level<br>
releases whenever there was a problem in the stdlib (and only<br>
then).<br>
<br>
Introducing new features by way of updates is left to<br>
minor releases, which then require more testing by the<br>
user.<br>
<br>
This additional testing is what causes many corporates to<br>
not follow the Python release cycle or skip a few minor<br>
releases: the work involved often just doesn't warrant the<br>
advantages of the added new features.<br></blockquote><div><br>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.<br>

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

<br>import sys<br>if sys.version_info >= (2, 7):<br>    import unittest<br>else:<br>    import unittest2 as unittest<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


The situations won't get any better if we start releasing<br>
partial or complete stdlib updates even more often.<br></blockquote><div><br>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.<br>

<br>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.<br clear="all">

</div></div><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>