<div dir="ltr"><div>Hi all,</div><div><br></div><div>Michiel: agreed, I put out Bio.Structure as a placeholder for now. Good point that it will invariably clash with a Structure class in there. Bio.structures is a good suggestion, I endorse the lowercase convention too!<br></div><div><br></div><div>FYI: This is an invite link to the Slack community where I created a #biopython channel. I don't want it to serve as an 'official' channel of communication, but I figure since we lost the '-dev' mailing list it's better if we can have some space to discuss this type of issues a bit more thoroughly without spamming the whole lot of you. Once we reach some consensus, we can update this post. Having said that, if you like 3D structures, static, dynamic, or frozen, feel free to join!<br></div><div><br></div><div><a href="https://join.slack.com/t/3dsig-cosi/shared_invite/enQtODA3MTM5OTE1OTU5LTdhZDMzZTY0MTBjYjk5NWIyZGEwMjZjZTQzNTdmNjhmNjk0OGI5NDQ2M2RiM2VlYTk1ZDY4Nzc5ZmU0MGIzYjM">https://join.slack.com/t/3dsig-cosi/shared_invite/enQtODA3MTM5OTE1OTU5LTdhZDMzZTY0MTBjYjk5NWIyZGEwMjZjZTQzNTdmNjhmNjk0OGI5NDQ2M2RiM2VlYTk1ZDY4Nzc5ZmU0MGIzYjM</a></div><div><br></div><div>Cheers,</div><div><br></div><div>João<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Michiel de Hoon <<a href="mailto:mjldehoon@yahoo.com">mjldehoon@yahoo.com</a>> escreveu no dia segunda, 21/10/2019 à(s) 03:41:<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><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:10px"><div></div>
        <div dir="ltr">Very much in favor of overhauling Bio.PDB. This is also a good opportunity to make the code organization more consistent with the rest of Biopython, for example by having "read" and "parse" functions instead of having to create parser objects first.</div><div dir="ltr"><br></div><div dir="ltr">I agree with João's idea of working under a new namespace. Since the new module will probably also contain a class named "Structure", I would suggest to give the module a different name, so we don't end up with the Structure class and a Structure module.</div><div dir="ltr"><span>To distinguish the two,</span> you could use "structures" for the module, and "Structure" for the class. We did something similar when we overhauled the old Bio.Motif module, creating a new module Bio.motifs, with a class named "Motif" inside.</div><div dir="ltr">Btw note that lowercase letters are recommended for module names in Python.</div><div dir="ltr"><br></div><div dir="ltr">Best,</div><div dir="ltr">-Michiel<br></div><div><br></div>
        
        </div><div id="gmail-m_-1052825104573875458yahoo_quoted_2548283019">
            <div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
                
                <div>
                    On Thursday, October 17, 2019, 7:23:21 AM GMT+9, 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:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="gmail-m_-1052825104573875458yiv0718986851"><div><div dir="ltr"><div>Hi Joe,</div><div><br clear="none"></div><div>IIRC from BOSC, my proposal was to work under a new namespace 'Bio.Structure' to avoid compatibility issues and, on the long term, deprecate Bio.PDB once all functionality had been rewritten.</div><div><br clear="none"></div><div>It would also be interesting to gauge what would be features people (users and developers) would like to see implemented/changed/fixed/removed.<br clear="none"></div><div><br clear="none"></div><div>The old car analogy is perfect :)</div><div><br clear="none"></div><div>Cheers,</div><div><br clear="none"></div><div>Joao<br clear="none"></div></div><br clear="none"><div><div dir="ltr">Joe Greener <<a rel="nofollow" shape="rect" href="mailto:jgreener@hotmail.co.uk" target="_blank">jgreener@hotmail.co.uk</a>> escreveu no dia quarta, 16/10/2019 à(s) 15:08:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div id="gmail-m_-1052825104573875458yiv0718986851yqt29045"><div>
<p>Hi Patrick,<br clear="none">
<br clear="none">
Some of us spoke about this at CoFest too, inspired by the ideas in Biotite (I don't think you and I spoke at BOSC though). As I recall it was João, Spencer, myself and possibly Peter in the discussions.<br clear="none">
<br clear="none">
We were in favour of the fundamental idea of a large coordinate array that is indexed into. As you point out though it would be no small amount of work to implement. I personally won't have time to do it, though I am happy to discuss and review code.<br clear="none">
<br clear="none">
I view Bio.PDB like a beloved older car that has been patched up over many years. It is probably the most widely used and debugged PDB parsing code around, and any overhaul would have to make sure to maintain the behaviour that many people rely on. That said,
 it does have its peculiarities and is rather slow (<a rel="nofollow" shape="rect" href="https://github.com/jgreener64/pdb-benchmarks" target="_blank">https://github.com/jgreener64/pdb-benchmarks</a>). I'm just saying that we should make sure to get consensus before merging
 any overhaul PRs. But for sure I am in favour of someone making those PRs.<br clear="none">
<br clear="none">
Best,<br clear="none">
Joe<br clear="none">
</p>
<p><font size="-1">Joe Greener<br clear="none">
Research Associate, UCL<br clear="none">
<a rel="nofollow" shape="rect" href="http://jgreener64.github.io" target="_blank">http://jgreener64.github.io</a></font><br clear="none">
</p>
<p><br clear="none">
</p>
<div>On 16/10/2019 12:37, Patrick Kunzmann wrote:<br clear="none">
</div>
<blockquote type="cite">
Hello Biopythoneers, <br clear="none">
<br clear="none">
at the BOSC this year we talked about overhauling the Bio.PDB module. The problem is that currently the atom coordinates are stored in a separate NumPy array for each atom. This design prevents efficient computation of all kinds of analyses (distances, angles,
 superimpositions, etc.). One proposed possible solution to this problem, we talked about, was to put the coordinates of the entire structure in one NumPy array, and let the Atom, Residue, Chain and Structure objects point to positions in this array. The benefit
 of this approach is that functions could be directly applied onto the entire array, harnessing the power of vectorization.
<br clear="none">
<br clear="none">
For the analysis we could adapt the vectorized functions from the Python package Biotite, a project I am currently working on (<a rel="nofollow" shape="rect" href="https://www.biotite-python.org/apidoc/biotite.structure.html" target="_blank">https://www.biotite-python.org/apidoc/biotite.structure.html</a>).
 Usually, these functions already accept the coordinates as NumPy array, so I think only a few tweaks would be necessary for every function.
<br clear="none">
<br clear="none">
However, we would require one person or a small team who makes the effort to implement the new structure types and adapts the analysis functions. I could offer a pair of helping hands in the adaption of the analysis functions, but I don't have the time for
 anything more. <br clear="none">
<br clear="none">
So the question is: Is there anyone out there, who is willing to do this work? Alternatively, I would propose to write a 'bridge' package between Biopython and Biotite, that converts the Biopython structure representation into the representation in Biotite
 and vice versa. I think, this solution is less elegant but would also require less effort.
<br clear="none">
<br clear="none">
Best regards <br clear="none">
<br clear="none">
Patrick Kunzmann <br clear="none">
<br clear="none">
_______________________________________________ <br clear="none">
Biopython mailing list  -  <a rel="nofollow" shape="rect" href="mailto:Biopython@mailman.open-bio.org" target="_blank">
Biopython@mailman.open-bio.org</a> <br clear="none">
<a rel="nofollow" shape="rect" href="https://mailman.open-bio.org/mailman/listinfo/biopython" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a>
<br clear="none">
</blockquote>
</div></div>

_______________________________________________<br clear="none">
Biopython mailing list  -  <a rel="nofollow" shape="rect" href="mailto:Biopython@mailman.open-bio.org" target="_blank">Biopython@mailman.open-bio.org</a><br clear="none">
<a rel="nofollow" shape="rect" href="https://mailman.open-bio.org/mailman/listinfo/biopython" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a></blockquote></div></div></div><div id="gmail-m_-1052825104573875458yqt40730">_______________________________________________<br clear="none">Biopython mailing list  -  <a shape="rect" href="mailto:Biopython@mailman.open-bio.org" target="_blank">Biopython@mailman.open-bio.org</a><br clear="none"><a shape="rect" href="https://mailman.open-bio.org/mailman/listinfo/biopython" target="_blank">https://mailman.open-bio.org/mailman/listinfo/biopython</a></div></div>
            </div>
        </div></div></blockquote></div>