<div dir="ltr"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>
<div id="m_695383405266471452bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px;line-height:auto">
<div id="m_695383405266471452bloop_customfont" style="margin:0px">This is a good
discussion to have, since this is a pretty central API
change.</div>
<div id="m_695383405266471452bloop_customfont" style="margin:0px"><br></div>
<div id="m_695383405266471452bloop_customfont" style="margin:0px">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.</div>
<div id="m_695383405266471452bloop_customfont" style="margin:0px"><br></div>
</div>
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.<br>
<div id="m_695383405266471452bloop_sign_1567686230532013824" class="m_695383405266471452bloop_sign"></div>
<div><br></div>
-Spencer
<div><br>
<p class="m_695383405266471452airmail_on">On 5 September 2019 at 12:41:03, Peter Cock
(<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>)
wrote:</p>
<blockquote type="cite" class="m_695383405266471452clean_bq">
<div>
<div><span>Maybe there should be an additional top level base class
(for all<br>
entities including Atoms), and define Entity a subclass of this
(for<br>
entities with children)?<br>
<br>
Would this help with defining the interface (even if Atom has its
own<br>
implementations of those methods)?<br>
<br>
Peter<br>
<br>
On Thu, Sep 5, 2019 at 12:07 AM João Rodrigues<br>
<<a href="mailto:j.p.g.l.m.rodrigues@gmail.com" target="_blank">j.p.g.l.m.rodrigues@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> A quarta, 4/09/2019, 09:08, Spencer Bliven
<<a href="mailto:spencer.bliven@gmail.com" target="_blank">spencer.bliven@gmail.com</a>> escreveu:<br>
>><br>
>> 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.<br>
>><br>
>> -Spencer<br>
>><br>
>><br>
>> On 4 September 2019 at 08:02:19, João Rodrigues
(<a href="mailto:j.p.g.l.m.rodrigues@gmail.com" target="_blank">j.p.g.l.m.rodrigues@gmail.com</a>) wrote:<br>
>><br>
>> Hi Spencer,<br>
>><br>
>> 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?<br>
>><br>
>> Thanks for the efforts in typing the module!<br>
>><br>
>> João<br>
>><br>
>> Spencer Bliven <<a href="mailto:spencer.bliven@gmail.com" target="_blank">spencer.bliven@gmail.com</a>> escreveu
no dia terça, 3/09/2019 à(s) 22:53:<br>
>>><br>
>>> 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?<br>
>>><br>
>>> 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.<br>
>>><br>
>>> -Spencer<br>
>>><br>
>>> _______________________________________________<br>
>>> Biopython mailing list -
<a href="mailto:Biopython@mailman.open-bio.org" target="_blank">Biopython@mailman.open-bio.org</a><br>
>>>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br>
><br>
> _______________________________________________<br>
> Biopython mailing list - <a href="mailto:Biopython@mailman.open-bio.org" target="_blank">Biopython@mailman.open-bio.org</a><br>
>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a><br></span></div>
</div>
</blockquote>
</div>
</div></div></div>