<div dir="ltr"><div>This exercise is really reinforcing the benefits of type annotations for me. I'm turning up lots of API issues that I wasn't expecting.</div><div><br></div><div>The latest twist is that DisorderedAtom <i>does</i> inherit from DisorderedEntityWrapper. So it expects atoms to be indexable like other entities. And we mix disordered and ordered entities everywhere, and they have different APIs, so there need to be type checks lots of places. Obviously this works now, but I think having the type checks is going to make writing correct parsers easier in the future.<br></div><div><br></div><div>-Spencer<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 2:56 PM Lenna Peterson <<a href="mailto:lenna.peterson@gmail.com">lenna.peterson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">That's my vote - more in keeping with LSP.<div dir="auto"><br></div><div dir="auto">Lenna</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019, 06:41 Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">Biopython@mailman.open-bio.org</a><br>
>>> <a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer noreferrer" 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" rel="noreferrer" target="_blank">Biopython@mailman.open-bio.org</a><br>
> <a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer noreferrer" 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" rel="noreferrer" target="_blank">Biopython@mailman.open-bio.org</a><br>
<a href="https://mailman.open-bio.org/mailman/listinfo/biopython" rel="noreferrer noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a></blockquote></div>
_______________________________________________<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" rel="noreferrer" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a></blockquote></div>