I don't think we should merge this without policy level discussion of AI generated code within Biopython (and perhaps even OBF projects generally). Copyright concerns in particular worry me (eg can this output be copyright and put under our license)?

Indeed, I believe it can! I replied on #5054

Thank you - as per my reply on #5054, what you describe sounds very reasonable if we as a project agree to accept AI generated code. I'm going to have to do more reading before forming an opinion.

Codecov Report

❌ Patch coverage is 71.42857% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.28%. Comparing base (d1c4b3d) to head (1085d47).
⚠️ Report is 29 commits behind head on master.

@@            Coverage Diff             @@
##           master    #5085      +/-   ##
==========================================
+ Coverage   85.45%   86.28%   +0.83%     
==========================================
  Files         286      282       -4     
  Lines       59854    59457     -397     
==========================================
+ Hits        51147    51305     +158     
+ Misses       8707     8152     -555     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Absolutely! I'm happy to contribute to any discussion regarding that, I'm no GitHub expert but I do believe very strongly in the power of (careful supervision of) AI agents and I'm happy to create any number of demonstrations to show it. Re non-trivial vibing, I love pushing the boundaries of these models' capabilities! Did you know that something like 95% of the code for Claude Code is actually written by Claude? Developers internally run sessions now for as long as 12 hours https://x.com/i/broadcasts/1vOxwdBqRwgKB

@rhowardstone Have you done some timings to find out why the C code is faster? We may get a similar speedup by simply modifying the Python code.

Cross reference https://mailman.open-bio.org/pipermail/biopython/2025-November/017094.html for another generative AI suggestion for Biopython.

I just posted a blog about my thoughts on receiving generative AI contributions as an Open Source project maintainer:

https://blastedbio.blogspot.com/2025/11/thoughts-on-generative-ai-contributions.html

In short I am sceptical, but to paraphrase myself from earlier in this thread - this PR seems like one of the best cases, but even here there is a real issue with a small pool of reviewers simply because this is in C rather than Python. Thank you.

@peterjc Interesting, very pragmatic post! Sorry for the delay; I've been swamped defending my thesis and applying to jobs. Got a very humbling laugh out of the "(often during their PhD)" line :)

Insistence on Python for code that is in any part AI-generated (perhaps, over some threshold in length, 5-10 lines could be trivial), I suppose, is one way of reducing the impacts of the quality/maintenance issues that arise here. There exists more (natural) training data for common languages, so code quality may be greater, and as you point out, you get a larger reviewer pool.

@mdehoon I'm happy to convert and benchmark! Are there other languages or variants the community would feel comfortable maintaining, like, Cython perhaps? It's quite simple to convert moderately, even complex code between languages now, at least with a robust test suite in place.

@rhowardstone Thank you. First step is to figure out where the speedup is coming from. Once we know that, we may be able to find a way to get a similar speedup in Python or numpy.
If it turns out that the speedup can only be obtained by using a compiled code, then the C code you currently have is the easiest to maintain.
But since few Biopython developers are familiar with C and Python/C glue code, Python or Python/numpy code is preferable by far.

tm_analysis_package.zip

Agent logfiles (for true reproduction, technically): chatlogs.zip

From the Claude Opus 4.5 instance that produces the above (zipped reproduction package):

Key Findings for PR #5085

Sequence	Original Python	C Extension	Fast Python	Speedup
16bp	21.36 µs	1.81 µs	6.20 µs	C: 11.8x, Py: 3.4x
20bp	23.16 µs	2.07 µs	6.62 µs	C: 11.2x, Py: 3.5x
28bp	30.45 µs	3.37 µs	10.23 µs	C: 9.0x, Py: 3.0x
36bp	33.79 µs	4.01 µs	12.64 µs	C: 8.4x, Py: 2.7x
50bp	42.85 µs	5.52 µs	16.98 µs	C: 7.8x, Py: 2.5x

Where the Speedup Comes From

1. Neighbor loop is the bottleneck (~52% of Python time for 28bp):

• Python creates string objects for each slice/concatenation (seq[i:i+2] + "/" + c_seq[i:i+2])
• Dictionary hash lookups add overhead

2. C extension wins by:

• Operating on raw char arrays (no object allocation)
• Linear search instead of hash tables (cache-friendly for small tables)
• No Python interpreter overhead

3. Pure Python optimization achieves 2.5-3.5x by:

• Using ord() integers instead of string operations
• Pre-computed tuple lookups indexed by bit-shifted integers
• Inlined calculations

Answer to @mdehoon's Question

"Have you done some timings to find out why the C code is faster? We may get a similar speedup by simply modifying the Python code."

Answer: The C extension achieves 8-12x speedup. Pure Python optimization can achieve ~3x speedup by avoiding string object creation in the hot loop. To match C performance in Python, you would need Cython compilation or NumPy batch processing for multiple sequences.

So if we can verify this, it appears we're able to get ~3x speedup over the current implementation using pure python. That implementation is included in the zip file. Does this analysis (README.md) fit with your intuition?

It makes sense that the deepest loop takes most of the time. It may be possible to speed the plain Python code up further by using

try:
    seq_bytes = bytes(seq) # this works for Seq objects and SeqRecord objects
except TypeError:
    seq_bytes = bytes(seq, encoding='ascii')  # this works for plain strings
seq_indices = np.frombuffer(seq_bytes, dtype=np.int8)

and then use these to index into the lookup tables.
Also, you can use

seq_bytes.count(b'C')

etc. to count the CG fraction.
The lookup tables can be extended by including the reverse complement and both lower and upper case. Then we don't need to check for that during the calculation.

I guess that then we get timings that are close, or close enough, to the C implementation.

Indeed, I believe that shaves some additional time off! However it doesn't get close to the ~10x speedup in C. I suppose, a mere 2.5-3x speedup is better than difficult to maintain code?

MDEHOON_RESPONSE.md

@rhowardstone Thank you for the timing. Can you please add your comments to this discussion, instead of attaching it as a file? That would make it easier for everybody to follow the discussion.

Sure, here's the markdown file Claude provides after testing the optimization approaches:

Response to mdehoon's Suggestions

Summary of Rigorous Benchmarks

I tested each of your suggestions individually on a 28bp sequence with 20,000 iterations:

Step-by-Step Timing Results

Step	Original	Your Suggestion	Speedup	Verdict
1. Sequence conversion	_check(): 3.41 µs	bytes() + filter: 2.12 µs	1.6x	✓ Helpful
2. GC counting	gc_fraction(): 1.42 µs	bytes.count(): 0.28 µs	5.2x	✓ Very helpful
3. Complement	Seq.complement(): 1.54 µs	inline dict: 2.78 µs	0.55x	✗ Slower
4. Index array	list comp: 1.25 µs	np.frombuffer(): 0.54 µs	2.3x	Mixed*
5. Neighbor loop	string concat + dict: 12.69 µs	int lookup + ext table: 5.29 µs	2.4x	✓ Helpful
5b. NumPy vectorized	—	64.16 µs	0.2x	✗ Much slower

*np.frombuffer() is faster in isolation, but the setup overhead negates gains in full function.

Full Function Results

Sequence	Original	Pure Python Optimized	Speedup
16bp	14.71 µs	5.81 µs	2.5x
28bp	23.30 µs	9.48 µs	2.5x
50bp	34.98 µs	15.90 µs	2.2x

Batch Processing Results

Even with batches of 10,000 same-length sequences, NumPy was still slower:

Batch Size	Pure Python	NumPy Vectorized	Speedup
100 seqs (20bp)	0.74 ms	1.80 ms	0.4x (slower)
1000 seqs (20bp)	7.16 ms	16.43 ms	0.4x (slower)
10000 seqs (20bp)	71.09 ms	163.51 ms	0.4x (slower)

What Works

1. bytes.count() for GC counting: 5x faster than gc_fraction()
2. Extended lookup tables (pre-compute reverse): Removes branch in hot loop, ~1.2x faster
3. Integer-indexed tuple lookups: 2.4x faster than string concat + dict lookup

What Doesn't Work

1. NumPy for single sequences: Overhead dominates (~60 µs setup vs ~5-15 µs computation)
2. NumPy for batch processing: Still slower due to per-sequence Python loop
3. Inline complement generation: Slower than Seq.complement()

Conclusion

Pure Python with tuple-indexed lookups achieves ~2.5x speedup. This is the best we can do without compiled code >because:

• The hot loop (neighbor calculation) is O(n) where n = sequence length
• Each iteration does minimal work (~200ns)
• NumPy's Python/C boundary crossing costs more than the computation itself

To match C's ~8-12x speedup, you need:

• C extension (current PR), or
• Cython (compile Python to C), or
• Truly vectorized batch processing where sequences are padded to same length and processed as 2D arrays with zero >Python loops

Recommended Minimal Pure-Python Patch

# Add at module level (~30 lines)
_B2I = tuple([...])  # base -> 0-3 index
_EXT_DH = tuple([...])  # pre-computed including reverse
_EXT_DS = tuple([...])
_EXT_OK = tuple([...])

# In Tm_NN, replace hot loop with:
for i in range(n - 1):
   b1, b2 = idx[i], idx[i+1]
   c1, c2 = _COMP_I[b1], _COMP_I[b2]
   j = (b1 << 6) | (b2 << 4) | (c1 << 2) | c2
   if _EXT_OK[j]:
       delta_h += _EXT_DH[j]
       delta_s += _EXT_DS[j]

This gives ~2.5x speedup with minimal code changes and no new dependencies.

Would you like me to have this minimal Python patch implemented, tested, and prepared as a PR?