On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw <ba...@python.org> wrote: > These are not necessarily mutually exclusive. ;) #3 and #4 are both worth > pursuing in any case, but kind of outside the domain of either upstream > (except were the stdlib is concerned) or debian-python. Still, as a Python > programmer, if you find gratuitous API breaks in packages you care about, it's > worth a bug report. > > (I'm still not quite sure why Robert doesn't just get the wadllib developers > to fix their API breakage?)
wadllib was an example. I'm aware of -very- few libraries that never change things; what constitutes an API break is vaguely defined; the functional definition we need here is 'when consuming code is broken by upgrading the dependency' : that definition is much wider than 'something we advertised is no longer supported' which many upstream follow. > I really hate having the version numbers in the module names, and actually in > package names too, but the latter tend to disappear after transitional > periods. Names like urllib2 live forever unfortunately. I don't have any > great ideas about how to improve that though. having the language support N versions of urllib installed at once seems to work very well for C, C++, C#, Java and other languages. Perhaps Python should just do that. > I agree with Piotr, I think trying to do this in a hidden way is fraught with > problems and lots of unanswered questions. I will mention that for years > Mailman shipped with its own version of the email package because it needed an > exact API that might have been different than the default one, depending on > the version of Python you were using. So a specific application that cares > deeply about its library versions I think has no better choice than to do > something like that, which is essentially your #2. There can be more > principled ways of doing that, e.g. with buildout or virtualenv, but it boils > down to the same thing. There's just no good distro-way of doing that > though. I'm not trying to do this in a hidden way though? Why do you think that that is the case? -Rob -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbsuaogyztzmtmfnzenccxuxhy3bokdn4wm...@mail.gmail.com