Codecov Report

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

@@            Coverage Diff             @@
##           master    #5054      +/-   ##
==========================================
+ Coverage   85.45%   86.29%   +0.84%     
==========================================
  Files         286      286              
  Lines       59854    59868      +14     
==========================================
+ Hits        51147    51663     +516     
+ Misses       8707     8205     -502     

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

Do I need to fix those? Sorry if I'm committing any faux pas: I am really quite new to GitHub contributions. By my understanding, that report is just pointing out that the 'fallback' code isn't used in the test environment? Happy to make any changes!

So, as part of a recent project, I created a full Tm replacement for BioPython's melting temperature calculations.

https://github.com/rhowardstone/AmpliconHunter2

Has "thermodynamic_tables.h" and "tm_nn_complete.c", which could completely replace Tm_NN. Is that something the community might be interested in?

For people doing large scale primer work, this could be great. I just called out to primer3 via Python bindings last time myself.

I've created a significantly enhanced version of this PR at #5085 that provides comprehensive acceleration for all Tm_NN calculations.

Key improvements over this PR:

• ✅ All 8 thermodynamic tables (vs 1)
• ✅ Internal mismatches (DNA_IMM1)
• ✅ Terminal mismatches (DNA_TMM1)
• ✅ Dangling ends (DNA_DE1, RNA_DE1)
• ✅ All 7 salt correction methods
• ✅ 10-30x speedup (vs 7x)
• ✅ Full BioPython test suite passes

The new implementation is based on AmpliconHunter2's comprehensive Tm engine and provides full API compatibility with BioPython's Tm_NN().

I'm closing this PR in favor of #5085. Please review the new PR for the complete implementation!

Generated with Claude Code, reviewed and tested by me.

Closing in favor of comprehensive implementation in #5085

This version was self written, right?

[See discussion on #5085 about the complications of using Claude Code.]

It was not; it was also 'nanny-coded': I haven't written C by hand in something like 15 years. Both versions were tested extensively using your test suite, ad-hoc tests written by the AI, and a use case scenario conducted by myself on its resulting code:

All melting temperature logic from AmpliconHunter ([Repo] [Webserver] [Publication - not yet up] [Preprint]) using BioPython's current Tm_NN was completely written by hand, and I've compared it to the annotated melting temperatures on AmpliconHunter2 ([Repo] [Webserver]) for the amplicons extracted from a set of 2.4M bacterial genomes (AllTheBacteria project) and others (see v2 webserver), using several primer pairs (admittedly, only targeting rRNA regions). All amplicons match melting temperature annotation within floating point precision (I rounded to some number of decimal places in v2 for brevity as thresholds are commonly integers). I plan to submit AmpliconHunter2 for publication this week, as this project forms the second chapter of my PhD thesis: I am quite certain of its correctness.

Re #5085, I understand completely if your policy as a community is "human-only", no offense taken! I don't personally agree with that, clearly :) -- I've worked very closely with agentic systems for about a year now, static LLMs for over a year before that, and was coding furiously by hand for years before that in pursuit of my Bioinformatics PhD: I'm confident of Sonnet 4.5's abilities (when paired with extensive testing). I used some variant of this memory file in all sessions for both PRs to navigate compaction issues for long scale tasks. I have also been developing a memory system for even better action-knowledgebase refinement. The latter was not used for any sessions here.

As far as legality, the current thinking at all these AI companies, I believe, is some form of Anthropic's Terms of Service statement, which explicitly addresses ownership of content generated by Claude. "Anthropic agrees that Customer (a) retains all rights to its Inputs, and (b) owns its Outputs" (current Anthropic Commercial Terms of Service). Essentially, as long as you aren't using Claude to create a competing AI, and you're otherwise following all local laws and regulations, you own anything you're causing to be created by these models. They even claim they'll back you up in court if anyone tries to say otherwise: "Anthropic will defend Customer and its personnel, successors, and assigns from and against any Customer Claim (as defined below) and indemnify them for any judgment that a court of competent jurisdiction grants a third party on such Customer Claim or that an arbitrator awards a third party under any Anthropic-approved settlement of such Customer Claim." where: ""Customer Claim" means a third-party claim, suit, or proceeding alleging that Customer’s paid use of the Services (which includes data Anthropic has used to train a model that is part of the Services) in accordance with these Terms or Outputs generated through such authorized use violates any third-party intellectual property right".

Again, though -- I understand completely if BioPython interfaces with so many things that this becomes a larger discussion than is worth it for such a small C program. I'm not offended at all, just figured I'd submit and see how it was received, since I have verified its correctness to my own standards (using your test suite). That said, it would of course be an honor for the code to be considered for merging, and I'm happy to do any additional testing on this iteration of it in order to satisfy us both of its correctness.

Thanks for all the great work you do!

Thank you for the clarification, and yes it sounds like the AI judgement applies equally this smaller PR #5054 and the larger #5085.

How you describe using this is to my mind pretty much the best case sceanario, and I have reasonble confidence that you at least understand the resulting code. It reminds me I want to read through https://mitchellh.com/writing/non-trivial-vibing as another example.

This is very different from the AI slop that many open source projects have reported getting, which is causing problems simply as a time sink (in addition to wider concerns such as legalities).

Let's continue on #5085 (locking this issue now to pre-empt a hard to follow spralling conversation in multiple places).