PDB.PDBIO.sav add end_ter = True

[pippo1990]

as noticing from https://stackoverflow.com/questions/78141949/modifying-values-in-pdb-file-and-save-as-new/78149130#78149130 could we have end_ter = TRUE in def save(self, file, select=_select, write_end=True, preserve_atom_numbering=False): (

biopython/Bio/PDB/PDBIO.py

Line 298 in d1f1aa8

def save(self, file, select=_select, write_end=True, preserve_atom_numbering=False):

)

so that settibg end_ter = False it will skip :

if chain_residues_written:
fhandle.write(
_TER_FORMAT_STRING
% (atom_number, resname, chain_id, resseq, icode)
)

[peterjc]

It sounds like you have a change in mind, perhaps a pull request would make it easier for us to understand your intent?

[JoaoRodrigues]

From the SO question, I don't see a reason to make this change (tbh neither for the optional END statement). Both statements are features of the file format and any parser will parse them correctly (or ignore them). What use case would you have where you need to write a pdb file without ter statements?

[pippo1990]

guess I'll have to install git and give it a try

[peterjc]

If you only want to edit a single file, then the GitHub editor in the browser works pretty well.

[pippo1990]

From the SO question, I don't see a reason to make this change (tbh neither for the optional END statement). Both statements are features of the file format and any parser will parse them correctly (or ignore them). What use case would you have where you need to write a pdb file without ter statements?

I have no idea we should ask https://stackoverflow.com/users/18253668/irene-ferfoglia , since the write_end is there , a write_ter could be plausible ? Don't know I am not expert, just tring github , for first time in my life ... I am thrilled, Thanks for your patience

[peterjc]

Well, you are learning about GitHub, pull requests, and automated style checking - but I agree with @JoaoRodrigues this really needs a justification, like a motivating example.

[rob-miller]

I think this is fundamentally why I proposed #3676 pdb residue string, and went ahead and implemented it inside the internal coords code (it shouldn't be there). The PDBIO code as it is doesn't support writing arbitrary chains or fragments like I needed to display the overlapping residue side chains in the documentation. (All this mostly from memory as I'm in a car now)

[JoaoRodrigues]

The problem is that then you're allowing the parser to write sort of non-compliant files :)

[rob-miller]

The problem is that then you're allowing the parser to write sort of non-compliant files :)

Yes, absolutely! Abusing PDB format is an old and venerable pastime for us dinosaurs. This is not for generating structures to submit to RCSB, it is for visualizing and analyzing data by manipulating structure viewers.

[pippo1990]

hi guys , sorry for using your time. Ended up by deleting my github repo twice, first time I commited and pulled from main fork, second time I just pulled request from github webpage ,but Joao asked for running pre-commit , so I removed everythiong again and now I am juggling with git and local repo , origin and upstreams on github, its kind of too much info at one time (my only previous experience was git locally to work on gl-inet ar-150 openwrt modding) .

Pre-commit by the way finds errors in PDBIO.py with black formatter , it actually doesnt tell about the formatting errors. Tried https://black.vercel.app/ , it is like is it reformats methods like:

def _get_atom_line(
self,
atom,
hetfield,
segid,
atom_number,
resname,
resseq,
icode,
chain_id,
charge=" ",
):

and the def save its a one liner so far , maybe gets too long with write_ter=True and gets caught by the formatter

Isnt that test run automatically by github too?

So I am stuck right now.. I'll try again later on

[peterjc]

If you're struggling with black, don't worry - we can tidy up the formatting as part of a PR on your behalf. Indeed, this can be automated - I'll open a new issue on that having touched on it in #4322.

So back to use cases, Rob has one 👍

[JoaoRodrigues]

OK for me then :)

[rob-miller]

I guess it’s obvious that I prefer #3676 pdb residue string as a solution here :-). I think it’s more efficient and flexible in that you can just spit it out during per-residue processing, and it’s a straight modularisation of PDBIO like writing individual atoms is already exposed. There might also be some aspect of “you know you’re hacking” using per residue primitives vs. “this must be condoned because it’s a supported option”.