[Biopython-dev] Fwd: Biopython - Bio.Restriction problem with super on python 2.6
biopython at maubp.freeserve.co.uk
Mon Oct 6 07:33:44 EDT 2008
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
---------- Forwarded message ----------
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,
I'll be able to check the unit test passes of a few different versions
> 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,
More information about the Biopython-dev