Feature Request: Faster Single-Base Access for Long Reads

[Crispy13]

Problem:

Right now, getting a single base from a pysam read (like read.query_sequence[i]) forces pysam to decode the entire read sequence first. For very long reads (thousands of bases), this can be slow if you only need one or a few bases.

Why it's needed:

When working with long-read sequencing data, if you just want a base at a specific spot on a read (e.g., for a barcode or a known variant position), decoding the whole lengthy sequence just for that one base wastes a lot of time and memory. Other tools (like rust-htslib) can grab just that one base much more efficiently.

Proposed Solution:

Add a new method to AlignedSegment, like read.query_base(index). This method would:

Directly fetch and decode only the requested base from the raw BAM data.
Avoid the overhead of decoding and creating a Python string for the entire read.
Return the single base as a bytes object (e.g., b'A').
Benefit:

This would make tasks that only need a few specific bases from long reads much faster, saving considerable processing time for large datasets.

[jmarshall]

Thank you for this suggestion, which points out a longstanding omission in pysam.

I got inspired and, rather than adding a function method like .query_base(index), thought to add a class member that would implement __getitem__, etc working directly from the raw BAM data and thus enable functionality like

read.query_bases[index]
read.query_bases[start:stop]
"A" in read.query_bases
read.query_bases.count("G")
…etc…

These would only need to decode the data they needed. Eventually implementing __setitem__ etc too would enable much richer possibilities for updating SEQ as well.

This is both more efficient and more expressive, and is what pysam probably should have had all along! There's a draft in PR #1347, but it will likely have its properties renamed etc before it is merged.

[jmarshall]

As for bytes vs str: I was thinking the thing to would be to provide both and let the user choose. Then I read the discussion on #29 and am less decided whether it is worthwhile.

[Crispy13]

Thank you for considering this.

Maybe people finding this feature want performance, so simple bytes is enough I think.