[Biopython] Atom inheritance from Entity

Spencer Bliven spencer.bliven at gmail.com
Thu Sep 5 12:38:15 UTC 2019


This is a good discussion to have, since this is a pretty central API
change.

Regarding Lucio's memory concerns, converting Atom to inherit from Entity
would require either 32 or 304 additional bytes per atom, depending on
whether child lists are initialized lazily or not (64-bit cPython uses 64
bytes for [], 240 for {}, and 16 for None). For comparison, a test
structure I loaded averaged ~1340bytes/atom. On the other hand, this
increases the complexity of the code in several places by requiring None
checks. We're currently setting `self.xtra = {}` in the constructor, so at
one point it was judged that simplicity outweighed the slight memory
savings. Certainly the memory savings from lazy initialization are slight
compared to what we could get by adopting the Biotite numpy-based
datastructure.

Myself, I like the consistency of defining internal nodes and leaves of a
tree in the same way, even if the child iterators are vestigial. However,
my concern now is establishing type hints, not changing the Atom API. So I
think that for the time being I will avoid changing things without clear
consensus.

-Spencer

On 5 September 2019 at 12:41:03, Peter Cock (p.j.a.cock at googlemail.com)
wrote:

Maybe there should be an additional top level base class (for all
entities including Atoms), and define Entity a subclass of this (for
entities with children)?

Would this help with defining the interface (even if Atom has its own
implementations of those methods)?

Peter

On Thu, Sep 5, 2019 at 12:07 AM João Rodrigues
<j.p.g.l.m.rodrigues at gmail.com> wrote:
>
> Wouldn't it be weird for an Atom to have a get_children method? I'm
somewhat more fine with a None attribute than a useless method.
>
> A quarta, 4/09/2019, 09:08, Spencer Bliven <spencer.bliven at gmail.com>
escreveu:
>>
>> Entity also provides methods for managing ids, transforming atoms, etc.
My preference would be for everything to inherit from Entity and just have
0 children. This is also consistent with Structure, which is an Entity with
'None' parent.
>>
>> -Spencer
>>
>>
>> On 4 September 2019 at 08:02:19, João Rodrigues (
j.p.g.l.m.rodrigues at gmail.com) wrote:
>>
>> Hi Spencer,
>>
>> Something that bugged me in the past as well. It would be nicer to have
everyone inherit from a single point, but since Atoms don't have children,
it would be confusing to have these methods there. My understanding is that
Entity only exists to provide methods to handle iteration over children
objects. It's a compromise?
>>
>> Thanks for the efforts in typing the module!
>>
>> João
>>
>> Spencer Bliven <spencer.bliven at gmail.com> escreveu no dia terça,
3/09/2019 à(s) 22:53:
>>>
>>> I was wondering why Atom doesn't inherit from Entity. It doesn't have
children, but it seems like it would be more consistent to have the whole
Structure stack inherit from a single point. Is anyone aware of the history
there?
>>>
>>> I ask because I'm trying to add type annotations to Bio.PDB, and mypy
flagged a number of places where my initial 'Entity' type conflicted with
Atoms. We can certainly get around this by accepting either Entity or Atom,
but I'm not sure that was intended.
>>>
>>> -Spencer
>>>
>>> _______________________________________________
>>> Biopython mailing list - Biopython at mailman.open-bio.org
>>> https://mailman.open-bio.org/mailman/listinfo/biopython
>
> _______________________________________________
> Biopython mailing list - Biopython at mailman.open-bio.org
> https://mailman.open-bio.org/mailman/listinfo/biopython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython/attachments/20190905/f8304d23/attachment.htm>


More information about the Biopython mailing list