[Biopython-dev] Fwd: Biopython - Bio.Restriction problem with super on python 2.6

[Peter]

This is a forwarded email from Frédéric Sohm about the python 2.6
super issue in Bio.Restriction (Bug 2604), with my replies included.
See also http://bugzilla.open-bio.org/show_bug.cgi?id=2604

Peter

---------- Forwarded message ----------
From: Peter
Date: Mon, Oct 6, 2008 at 11:09 AM
Subject: Re: Biopython - Bio.Restriction problem with super on python 2.6
To: Frederic Sohm

On Mon, Oct 6, 2008 at 9:20 AM, Frédéric Sohm wrote:
> Hi Peter,
>
> I do not have access to the mailing list (I suspect my e-mail address
> changed since my inscription to the biopython and biopython-dev mailing list
> (from ... to ...)

You can sign up again if you like, http://biopython.org/wiki/Main_Page

Do you mind if I forward this to the mailling list (I'll remove your
email addresses if you are worried about spam).

> Concerning the sets problem :
> I prefer the following solution rather than change all Set occurences :
>
> Replacing the import :
>
> from sets import Set
>
> by :
>
> import sys
> if sys.version < '2.6' :
>        from sets import Set
> else :
>        Set = set
>
> This should maintain backward compatibility with python 2.3 as you requested
> on the mailing list and avoid to have to change too much code, on the other
> hand its not as clean as changing Set occurences.

Either would work - I don't really mind.  I think we'll have to change
all the Set occurances one day, so we might as well do it now.

> Concerning the Restriction module, it was easiest than I thought it would be:
>
> I replaced line 221 :
> super(RestrictionType, cls).__init__(name, bases, dict)
>
> #dict was an error for dct by the way

I had wondered about dict/dct, so its good to have that confirmed.

> By :
>
> if sys.version < '2.6' :   # sys is imported at the beginning to check
>                           # for set anyway.
>     super(RestrictionType,cls).__init__(name, bases, dct)
> else :
>     super(RestrictionType,cls).__init__(cls, name, bases, dct)
>
> # cls is the equivalent of self there. It's different to mark the fact
> # that the class is a metaclass not a normal python class.
>
> This should support both 2.6 and 2.3; The biopython test is now working with
> 2.6 (I did not try with 2.3 but this should not have changed anything for
> this version). I have not much time for testing it thoroughly right now,
> sorry.

I'll be able to check the unit test passes of a few different versions
of python.

> I attached the 2 files I modified : Restriction (set and super) and
> CodonTable (set). Could you please take care of the uploading as I have no
> access to it.

Yes, of course.

> =====================================================================
> To explain a bit what happen there :
> I had problems of inheritance when I tried to build this module :
> Restriction enzymes are defined by a serie of site characteristics and ways
> to cut the DNA (blunt/3' overhang/5' overhang, one/two cut(s),
> inside/outside the recognised sequence,...).
> This implied I could not find a way to write a generic enzyme classes with
> standard methods without being confronted to inheritance and mro (method
> resolution order) problems when instantiating the final class.
>
> One way out would have been to check each single class instance for all the
> characteristic with series of if/else in every method over and over. But
> this would have been tedious to write, slow and not very much in the spirit
> of an object-oriented programming language.
> Moreover I was curious to see how metaclass worked.
> So I used metaclass to build the class for the enzyme.
>
> That way each single enzyme is its own class, which is put together from a
> serie of basic class. These classes are combined to build a metaclass for
> each enzyme. By putting the class together that way I managed to overcome
> the method resolution order problems (diamond rule).
>
> The main drawback is that Restriction uses directly classes to do the work
> instead of "normal" python class instances.
> Some magic is then necessary to initiate the classes and create the class
> instances (hence the use of super and the magic at the end of the
> Restriction.py module - from "for TYPE, (bases, enzymes) ..." onward).
>
> I am not certain this way is the recommended way to do it, but on the other
> hand,  it's working, fast enough and it was fun to write so...
> =====================================================================

Great - thanks,

Peter