[Biopython] Phasing out support for Python 2.4?

[Martin Mokrejs]

Hi Peter,
  I just had troubles with 2.5 to 2.6 move (mailman needed manual patches),
and just envisioned that similarly 2.4 to 2.5 would be a trouble. So, personally
I don't mind but I would prefer clear listings what modules require the
newer features and having an option to skip them during install step them
instead of having to blindly upgrade. Personally I just use Bio.SeqIO and that
is probably all I need. ^H^H^H^H^ and Entrez or PubMed or Efetch stuff, I got
lost in the many biopython deprecations and module renames in the last years.
I use the "latest" but forgot how is it currently named. ;-) ^H^H^H^H^H of
course I know, efetch(). ;-)
  Recently I had for example install some old Solaris 2.6 machine with some
apps and imagine, was glad to have python 2.3 I think with gcc-3.x at all.
Martin

Peter wrote:
> On Thu, Jan 14, 2010 at 4:04 PM, Martin MOKREJŠ
> <mmokrejs at fold.natur.cuni.cz> wrote:
>> Hi Peter,
>> I don't get this point much. What is the problem stating that with
>> python 2.5+ one does not need to install an extra dependency while
>> for 2.4 one needs _two_ modules?
>> I don't think I want BioSQL nor sqlite so why would I have to upgrade.
>> Would the requirement be in python language syntax incompatibility then
>> I would NOT object, but in this situation ...
>> Martin
> 
> Hi Martin,
> 
> This isn't just the issue of sqlite3 and ElementTree. There
> are several benefits to using more recent versions of Python,
> for example with an eye on the future for Python 3, and on
> a practical level it simplifies our testing to have one less
> version to worry about (especially once Python 2.7 is out,
> currently scheduled for June 2010).
> 
> We've already had minor issues with developers using
> Python 2.5+ syntax unwittingly which broke on Python
> 2.4 (nothing major, and it was easily fixed once the
> problem was spotted). If we continue to insist on Python
> 2.4 support, it may prove problematic for if future potential
> contributors have existing code written for Python 2.5+
> which would require significant re-factoring.
> 
> None of these concerns are pressing right now (and
> some are hypothetical), but I think you will agree that
> Python 2.4 is pretty old, and not widely used anymore.
> Having a clear plan in place for dropping it seems a
> sensible move, and once that happens we can start
> to take advantage of the language and library
> improvements Python 2.5 added.
> 
> Are you personally using Python 2.4? If so, could you
> tell us a little more - for example, is this a university
> server which would be difficult to update? Or do you
> require some other Python package which requires
> Python 2.4?