Closed lutzfischer closed 3 years ago
Thanks for reporting. I have reproduced the issue and will shortly look into ensuring a fixed order of output.
@lutzfischer I got rid of sets and also sorted the variable_mods
dict just in case, so the order should now be more stable. Could you please check the latest version in master?
Hi,
I checked out current master and tried it. The output is now reproducible, but it looks like you introduced a bug concerning terminal modifications with these changes.
When running e.g.:
parser.isoforms('AAA', fixed_mods={'n-': True, '-c': True})
I now get:
File ".../pyteomics/parser.py", line 838, in isoforms
parsed[i] = apply_mod(group, cmod)
File ".../pyteomics/parser.py", line 795, in apply_mod
group = list(label)
TypeError: 'NoneType' object is not iterable
Ah, thanks for the catch! Indeed, I broke the fixed modifications with my change. They should be fixed now (haha).
Hopefully this is resolved now, please report any problems with new isoforms
.
yep, works fine now :+1: Thank you!
Hi,
We I noticed a problem (at least for us) in how
isoforms
reports modified peptides. If there are two or more modifications defined that have the same/overlapping specificities, then the order in which these get applied to any given residue is undefined. E.g. given the peptideXXXKXXXX
and two variable modification,a
andb
, that could happen onK
the isoform-function will sometimes yieldsXXXaKXXXX
,XXXbKXXXX
and sometimesXXXbKXXXX
,XXXaKXXXX
(only differs when the python interpreter is restarted in between - just running it twice directly one after the other yields the same order) . On itself this is not a big problem - but we have to cap the total number of reported modified peptides. And having a non defined order then leads to different subsets of modified peptides being used.I suspect the problem comes from the use of sets for encoding the possible modifications on each residue of a peptide.