DEV Community: Emmimal P Alexander

Product Autopsy: My Auditor Flagged 18 Broken Promises in My Own Repos. Four Were Real

Emmimal P Alexander — Sun, 18 Oct 2026 04:39:58 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

My own README told readers: “Push it before publishing this table, or remove the row until it is.”

That sentence is a note to the author. It had been sitting in a public repository for about two months, visible to everyone who opened it, and I hadn’t noticed. A tool I wrote found it.

The tool is Product Autopsy. A seller can have a polished listing and still ship a product that breaks its promises: “includes setup.xlsx”, “totals update automatically”, “ready in five minutes”. Most AI tools for sellers help write the listing. Product Autopsy checks the listing against the actual files, using deterministic checks where possible and a local model when the wording is too varied to parse. It reads a product folder the way a disappointed buyer would:

Missing files. The docs mention a file that isn’t in the package.
Broken links. A local link doesn’t resolve: a missing target, the wrong letter case, a path that escapes the package, or a #anchor with no matching heading.
Wrong spreadsheet totals. A SUM range that doesn’t match its data, a total that sums the wrong column, or a result that differs from the number the README promises. A small local model proposes claims from the prose. Plain code decides what is true. A validator rejects claims that fail the source-grounding and workbook checks, leaving them for human review rather than silently repairing them.

I ran it on 30 of my own public repositories. It flagged 18 candidates. I opened every one by hand: 4 were real, all from one repository, and I fixed them in one commit. The other 14 were false alarms, and they taught me more than the hits did.

Who would pay for this

Anyone who sells a digital download and gets support emails that start with “the file you mentioned isn’t in the zip”: spreadsheet and template sellers, authors of guides with companion files, people shipping starter kits. A broken promise costs a refund, a bad review or a support thread. And the thing being audited is usually a product that hasn’t been released yet, which is why it matters that this runs on the seller’s own laptop.

My hypothesis for the business: keep the audit free and local, and charge for a written report, batch audits of a whole catalogue, or a hosted version. That is a hypothesis. Nobody has paid for this, and the “My First User” section says exactly what I did and didn’t test.

Demo

Product Autopsy is a command-line tool, so there is no deployed link. A seller runs one command on a product folder, reads a plain-language report, fixes what it lists, and runs it again before launch.

A deliberately broken sample product. The defects are planted by my benchmark script:

$ python autopsy.py samples/budget-planner --report
Product Autopsy report: budget-planner
3 problem(s) found, 6 check(s) passed

FAIL  broken link   README.md: `docs/refund-policy.md` does not resolve (missing, or the letter case differs)
FAIL  missing file  README.md: `setup.xlsx` is named in the docs but is not in the package
FAIL  spreadsheet   tracker.xlsx: `Total Revenue`: the SUM range does not match the data rows; the result differs from the number the README promises

A clean control. All 3 checks pass for this product:

$ python autopsy.py samples_phrasing/tutor-tracker-right --report
Product Autopsy report: tutor-tracker-right
0 problem(s) found, 3 check(s) passed

No problems found among the promises this version can check.

Those two are generated test products. Now a real repository of mine. Before the fixes, the scan of my 30 repos flagged 18 candidates, and I checked each one by hand. Four were confirmed defects, all in graph-density-engine. This is the tool’s output for those four rows:

graph-density-engine | missing_file | datasets/incident_01.json | experiment.md | referenced_file_absent
graph-density-engine | missing_file | incident_10.json | experiment.md | referenced_file_absent
graph-density-engine | missing_file | run_experiment2.py | README.md | referenced_file_absent
graph-density-engine | missing_file | agents/llm.py | requirements.txt | referenced_file_absent

Flagged path	What it turned out to be
`run_experiment2.py`	A leftover author note in the README, “Push it before publishing this table”, about a table row that no longer existed
`datasets/incident_01.json`	A missing data file: the Quick Start fails on a fresh clone
`incident_10.json`	The same missing data files
`agents/llm.py`	A stale comment in `requirements.txt` pointing to a file that doesn’t exist

The other 14 candidates were false alarms. My verdict on each is in verify_findings.md, and the raw scan is in real_findings_before_fix.csv.

After commit c93d44e, I rescanned. It flagged 14 candidates, the same 14 rows I had already classified as false alarms. In graph-density-engine the only remaining row is results.json, a file a command creates when it runs. The before and after scans are saved as results_before_fix.md, real_findings_before_fix.csv and real_findings_after_fix.csv.

Code

Emmimal / product-autopsy

A Python-based tool that audits product and repository claims against actual project files, identifies broken promises, and evaluates finding accuracy across deterministic, clean-phrasing, and noisy-phrasing benchmarks.

Product Autopsy

Checks whether a digital product (a spreadsheet, template pack, guide or starter kit) delivers what its listing promises. It reads a product folder the way a disappointed buyer would and tests every promise it can verify against the actual files.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 2: Side Hustle. A small local model (Gemma 3 1B through Ollama) reads promises written in prose. Plain code decides what is true. A validator rejects model claims that fail the source-grounding and workbook checks and leaves them for human review.

Write-up: Product Autopsy: My Auditor Flagged 18 Broken Promises in My Own Repos. Four Were Real

What it checks

Check	What it catches
Missing file	A document names a file that is not in the package
Broken link	A local Markdown link that does not resolve: missing target, wrong letter case, a path outside the package, or a

…

View on GitHub

The repo has the checker, the benchmark and hold-out generators, the Gemma claim extractor and the scripts that produce every table in this post.

Run it

You need Python, Git and Ollama installed. Install the Python dependency and download the model once:

pip install openpyxl
ollama pull gemma3:1b

Make sure Ollama is running before starting the model experiments. Then run:

python run_all.py gemma3:1b --real

run_all.py generates the benchmark, runs the checks, clones my 30 repositories if they are not already present, scans them, runs both hold-out experiments and saves the results to results.md. Leave out --real to skip the repository scan, or leave out the model tag to skip Gemma. Once the samples exist, you can try the seller-facing checker on the deliberately broken sample:

python autopsy.py samples/budget-planner --report

The synthetic benchmarks and hold-out experiments are generated by these commands. The prompt-v1 results came from an earlier prompt version and are saved in results_1b_prompt_v1.md. The original scan of my repositories was run before the fixes; the command reuses existing repository folders and does not recreate that pre-fix state. The saved outputs include results_before_fix.md, real_findings_before_fix.csv, real_findings_after_fix.csv and my manual verdicts in verify_findings.md. The first realistic-README run, which caught 5 of 10 wrong totals, is saved in results_noisy_run1.txt.

How I Built It

The stack is deliberately small: Python’s standard library, openpyxl to read .xlsx files, and Gemma 3 1B running locally through Ollama. No API keys and no calls to outside services during a check; the model runs on the same machine.

The model reads, the code judges

The three checks themselves (missing files, broken links and spreadsheet totals) use no model. The model is there because promises come in endless wordings. A regex handles the one phrasing I wrote it for, while a model can read “revenue comes to 1,640 in total” and “the sample revenue column sums to 1,640” as the same kind of claim. The model has one job: read the prose and return claims such as “the Total Revenue cell shows 1,640”, as JSON, with the schema enforced and the temperature at 0. It never decides whether a claim is true. Every claim must pass five checks in plain code, or it goes to human review and is never repaired:

It matches the expected JSON structure and uses a supported claim type.
It comes from a file that exists in the product.
The claim text appears in that file (ignoring case, spacing and Markdown marks).
The promised number appears inside that claim text.
The target is one of the total labels that code read from the workbook itself, and its key word appears in the claim text. That last rule came out of a failure, described below.

Benchmark one: 30 planted defects

I generated 10 sample products with a script. Each has one planted defect per category (missing file, broken link, wrong spreadsheet total) plus valid controls, 60 valid checks in all, so false alarms can be measured. The ground truth lives in a separate file the checker never sees.

Category	Planted defects	Recall	Precision	False-positive rate
Missing file	10	100%	100%	0%
Broken link	10	100%	100%	0%
Spreadsheet	10	80%	100%	0%
All	30	93%	100%	0%

The two misses are on purpose. In two products I wrote the promised total in free phrasing (“revenue comes to 1,640 in total”) that my regex can’t parse. That gap is where a model should help.

I wrote both the generator and the checker, so these numbers show the engine works. They don’t show it finds defects in the wild. The next two sections are the ones that matter.

Benchmark two: what Gemma 1B actually did

I ran it on a CPU-only laptop with 7.4 GiB of RAM, about 1.1 GiB of it free, and no usable GPU. It took three experiments, because the first one gave an answer I didn’t trust.

Experiment 1: the main benchmark. Two of the products promise a total in free phrasing that my regex can’t parse. I tried two prompts.

Run	Claims accepted	Rejected by the validator	New defects caught
Deterministic only	n/a	n/a	n/a
Gemma 1B, prompt v1	7	23	0
Gemma 1B, prompt v2 (workbook labels and one worked example)	5	2	0

Prompt v1 produced mostly noise: 23 of 30 claims were rejected. For v2, my code read the real total labels from each workbook and handed them to the model along with one example from a different domain. Rejections fell to 2, but recall did not move. All 5 accepted claims were the same sentence my regex already handled, and the model never extracted either free-phrased promise.

The two rejected claims show why the validator exists. For one product, the model quoted “Etsy Profit Sheet helps you see profit per listing. Everything lives in one workbook.” and attached the number 1537. For another it quoted “Import categories.csv into the Categories tab.” and attached 1475. Neither number appears in either sentence. Without the grounding rule, those values would have been compared against real workbook totals and could have produced false accusations against a seller.

That looked like a clear answer, but it rested on two products, and I had adjusted the prompt after seeing them. So I built a fresh test.

Experiments 2 and 3: a hold-out set. I generated 20 new products. Each has a correct workbook and one sentence promising the Total Revenue in natural wording. There are 10 different phrasings, each used twice: once with the wrong number (a defect) and once with the right number (a control). None of the sentences matches my regex, so the deterministic baseline catches 0 of 10. I did not change the prompt after seeing these results. I ran the same 20 products twice: once with a one-sentence README, and once with a realistic README around the promise (a file list, setup steps, links, and an unrelated sentence saying “every total updates automatically”).

Setting	Deterministic baseline	Gemma 1B	False alarms
Main benchmark: 2 free-phrased promises in realistic READMEs	0 of 2	0 of 2	0
Hold-out, one sentence per README	0 of 10	8 of 10	0 of 10 controls
Hold-out, realistic README around the promise, run 1	0 of 10	5 of 10	0 of 10 controls
Hold-out, realistic README around the promise, run 2	0 of 10	4 of 10	0 of 10 controls

Gemma 1B does add recall: it catches wrong totals that my deterministic checks can’t read. It is also fragile. Wrapping the same sentences in a realistic README cost 30 to 40 points of recall. In the noisy run the validator rejected 6 claims: 4 were spreadsheet claims with no number and 2 quoted text that couldn’t be found in the README. In all three hold-out runs none of the 10 correct promises was flagged, so no false accusation came out of these tests, though 10 controls per setting is a small check.

Three cautions. First, the realistic-README result isn’t stable: I ran it twice with the same code, the same data and the temperature at 0, and the results were not identical: 5 of 10, then 4 of 10 (repair-desk-wrong was caught once and missed once). The one-sentence set and the main benchmark reproduced exactly. Second, ten defects per setting is a small sample, so I wouldn’t call 80% against 40–50% a solid difference; I’d call it a warning. Third, I built both the products and the phrasings, so these results are still synthetic. They show where a small model starts to fail, not how it performs on real listings. I haven’t tested a larger Gemma, and I haven’t compared against a hosted model, so I won’t claim anything about either.

The real test: 30 of my own repos

I cloned and scanned 30 of my public repositories. The scan covered 216 checks: 206 file mentions and 10 local links. All 10 local links resolved. The file-mention check flagged 18 candidates, which I then reviewed manually.

I classified each flag as a confirmed defect, an expected absence, or uncertain, by opening the file and reading the surrounding text.

Verdict	Count	Why
Confirmed defect	4	One leftover note, two missing data files, one stale comment
Expected absence	14	Example paths in a sample agent chat, an archived design table and a simulated repo (9); a file a command creates when it runs (1); a negation, “No requirements.txt” (1); an example argument (1); a path on the reader’s own machine (1); an identifier in prose (1)

The four real rows come from three causes, all in graph-density-engine:

A leftover note to the author in the README, “Push it before publishing this table”, about a table row that no longer existed.
Missing data files. During the original scan, the README's Quick Start loaded incident_01 through DatasetLoader, but the required dataset JSON files were absent. On a fresh clone at that time, the Quick Start failed with FileNotFoundError. I reproduced it before restoring the files. I regenerated the datasets with fixed seeds, but I cannot prove they are byte-identical to the originals used for the published experiment.
A stale comment in requirements.txt pointing to agents/llm.py, a file that doesn’t exist, while the README says there is no model anywhere in the pipeline. The fix is one commit: c93d44e. I couldn’t find my original data files, so I regenerated them with the generator’s fixed seeds. The generator uses a fixed seed for each scenario, so the files should match, but I can’t prove they are byte-identical to the ones behind my published numbers, and I’d rather say so than imply it.

After the fix, a rescan flags 14, and every one is a false alarm I had already classified. Zero confirmed defects remain, which shows the find-and-fix loop works. It doesn’t show the repos are clean. The scan outputs from before and after the fix are saved in the repo, so the 18-to-14 change can be checked.

Precision on real repositories was 4 of 18, about 22%, and all four came from a single repo. I’d call the file-mention check useful for finding candidates and not yet good enough to trust unattended. Before scanning my own repos I tuned the noise filters on four third-party template repos, so those four don’t count as a clean test. The only change I made after seeing my own results was the path fix described below.

Two bugs the checker had

Running on real machines found two bugs in my own tool.

Windows hid case-mismatch links. On my Windows laptop, broken-link recall was 80% and overall recall was 87%, lower than on Linux. My code used Path.resolve(), which on Windows rewrites a path to its real on-disk case, so Guide.MD pointing at guide.md looked fine. It would break for a Linux reader. I replaced it with plain path arithmetic, and the numbers matched on both systems.
Paths that climb a folder. A mention of ../RESOLVER_RULES.md was flagged as missing even though the file exists. I fixed the path handling. This is a correctness fix made after seeing the real-repo results, and I’m reporting it as one.

What it can’t see

It skips fenced code blocks to avoid noise from examples, so a file listed in a README’s code-fenced tree can slip through. My graph-density-engine README lists phase2_results.json in its project tree, and that file isn’t in the repo. The checker missed it.
It reads files and never runs a product’s instructions. A Quick Start that fails when you run it is invisible to a tool that only reads. Running the instructions, the “buyer disappointment simulator” in my original pitch, is the obvious next build.
I have no recall number for real repos. I know what it flagged. I don’t know what it missed.

What I’d build next

Test a larger Gemma on the realistic-README hold-out set, where the 1B model drops to 40–50%.
Flag a file mention only when it sits in an instruction like “open”, “copy” or “run”, to cut the false alarms, and test that on a fresh set of repos.
Run the Quick Start itself.

Why Does Open Innovation Matter?

The product folder never leaves the machine. The thing being audited is often unreleased work. Sending a seller’s unpublished files to a hosted API is a poor trade for a pre-launch check, and with a local model it isn’t needed.
The model is replaceable. The checker doesn’t care which model fills the claim slot. Swapping Gemma 1B for a larger local model means changing one tag, and I can measure the difference with the same benchmark.
No per-audit API fee. The audit runs locally with Python, openpyxl and a downloaded Gemma model. There is no hosted-model charge per check, although the model still needs storage, hardware and electricity. That is what makes a free local tier possible at all.
The design doesn’t depend on trusting the model. The validator is designed to reject unsupported claims before they become findings. That reduces one class of model error, but it doesn’t guarantee that every accepted finding is correct. In my runs, a 1B model caught up to 80% of the wrong totals my regex couldn’t read, fell to between 40% and 50% with realistic text around the promise, and produced no false alarms on the controls, though the tests are small. Where open fell short: the 1B model is fragile. Recall dropped from 80% to between 40% and 50% when I added realistic text around the promise, and a larger local model might fix that, which I haven’t tested. I haven’t compared against a hosted model, so I can’t tell you whether a closed API would have done better. What I can say is that an open model made the privacy and cost story possible, and the validator provided a checkable boundary around what the model could submit as a finding.

My First User

My first and only user so far is me, on 30 repos. No seller has tried it, and nobody has paid. I won’t claim that anyone would, because I don’t know.

What I do know is that it surfaced four things I had missed in my own published work, and that the false alarms are as informative as the hits: they show exactly where a seller would get annoyed. The next test that matters is handing it to a seller and asking whether the flags helped or irritated them.

Prize Categories

Best Use of Gemma

Gemma 3 1B, run locally through Ollama on a CPU-only laptop, reads README prose that my regex can't parse and proposes claims as JSON. On a hold-out of 20 products it caught 8 of 10 wrong totals in short READMEs (baseline: 0) and 4 or 5 of 10 in realistic ones. Most of this post is about what it took to make a 1B model's claims safe to act on: a validator that rejects anything it can't ground in the source. The tables are in "How I Built It".

ButterflyBench: I Changed One Instruction. What Else Did the AI Change?

Emmimal P Alexander — Wed, 07 Oct 2026 10:36:14 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

One of my test prompts said: "Read JSON files instead of CSV."

In more than half of my reruns, three models answered by also setting the delimiter and the header-row setting to unspecified. They weren't wrong. A JSON file has no delimiter and no header row. My scoring code was wrong, because it assumed the other 19 settings had to stay exactly as they were. That mistake taught me more than any leaderboard number, and it's what this post is really about: checking whether a model changes only what you asked it to change is harder than it sounds, for the model and for the person writing the test.

I keep running into the same question in my own work with prompts and code: when I change one thing, what else breaks? An assistant can make the edit you asked for and still move something you never mentioned. So I built ButterflyBench to measure that directly.

The name comes from the butterfly effect idea: a small change can produce effects elsewhere, and I wanted to measure how much of that happens in an AI's specification.

How it works. Every scenario starts from the same 20-setting specification for a command-line data tool. It covers the Python version, input and output formats, sorting, encoding, timeout, delimiter, header row, logging level and so on, and it's described to the model in plain English. Over one to ten turns, a simulated user edits it. The user might:

set a value ("Give each file a 60-second timeout.")
undo the last change, or a change described indirectly ("Undo the change to how dates are printed.")
undo "the earliest change that is still in effect"
redo a change that was just undone
drop a requirement ("Sorting no longer matters.")
say something that must change nothing, like a question or a remark about a teammate's setup

After every turn the model has to restate the full specification as JSON. I also stated three coupling rules up front: TSV input forces a tab delimiter, parallel processing turns the progress bar off, and HTML output forces UTF-8. That way a required side effect isn't mistaken for collateral damage.

There is no LLM judge. A small Python oracle replays the active changes after every turn and works out the exact correct specification. The Kaggle score is the share of the 40 scenarios whose final specification matches exactly. Offline I also compute change radius (how many settings moved without being asked), recovery after an undo, and the first turn where a model went wrong.

There are 40 scenarios: 6 I wrote by hand and 34 generated from templates with a fixed random seed. They cover undo by indirect description (6), undo the earliest change still in effect (6), coupled rules (6), distractors (5), undo last (4), cancel (4), long chains (4), redo (3), and one each of cancel-then-undo and indirect reference.

I'm not claiming to have invented any of this. Multi-turn instruction following is well studied, for example in Multi-IF, MultiChallenge and EvolIF. What I wanted was something small and reproducible, with an exact answer key, where the headline question is collateral change.

My first pilot was too easy. It had 10 settings and scenarios of one to three edits, and Gemini 3.7 Flash scored 5 out of 5. I rebuilt it with 20 settings, undo, redo, indirect references, distractors and coupled rules, and that version started to separate models.

Models Tested

I ran seven models from four providers: Gemini 3.7 Flash, Grok 4.20 (both the reasoning and non-reasoning versions), Claude Sonnet 5, Claude Haiku 4.5, GPT-5.4 mini and gpt-oss-20b.

I chose them by a rule I fixed before I saw any results: a spread of providers and sizes, plus a reasoning and a non-reasoning variant of the same model where one existed, which Grok 4.20 offers. Practical limits shaped the lineup too, mainly Kaggle's daily AI quota and which models its Add Models list offered. Every model got the same 40 scenarios, prompts and settings (the library defaults, temperature 0 and seed 0). Sonnet 5 ran with an 8,000-token output cap, which is far more than the few hundred tokens a reply needs.

Findings

A note on the numbers first. The leaderboard below is the public Kaggle run, one run per model. During development I also ran the same scenarios locally, some of them against an earlier version of the scenario set. Those runs varied by as many as six scenarios for the same model, and the detailed table further down comes from a separate local run, so its totals don't match the leaderboard exactly. Please read the leaderboard as a snapshot, not a ranking.

The most interesting result wasn't the leaderboard. It was that models with similar scores failed in very different ways.

Model	Score (40 scenarios)
Grok 4.20 Reasoning	1.00
Claude Sonnet 5	1.00
Gemini 3.7 Flash	1.00
gpt-oss-20b	0.90
Claude Haiku 4.5	0.78
GPT-5.4 mini	0.75
Grok 4.20 Non-Reasoning	0.75

Across all my runs, gpt-oss-20b scored anywhere from 30 to 36 out of 40, Haiku 29 to 31, GPT-5.4 mini 27 to 30 and Grok non-reasoning 27 to 30. So the gaps among the three lowest models are inside the noise, and the top group is one run each.

The hard part is history, not editing

For one final local run I looked at four models in detail. Three of them, Haiku, GPT-5.4 mini and Grok non-reasoning, behaved almost identically:

Category (scenarios)	Haiku 4.5	GPT-5.4 mini	Grok non-reasoning	gpt-oss-20b
Undo the earliest change still in effect (6)	0	0	0	6
Undo the last change (4)	4	4	4	3
Undo by indirect description (6)	6	6	6	5
Redo (3)	3	3	3	2
Coupled rules (6)	6	5	3	5
Cancel (4)	3	3	3	4
Distractors (5)	4	5	5	4
Long chains (4)	1	2	1	0
Total (40)	29	30	27	30

Those three handle "undo that last change", "undo the change to X" and redo without any trouble. What they can't do is "undo the earliest change that is still in effect", where the target has to be worked out from which changes are still active. In my first full run, GPT-5.4 mini failed all ten scenarios containing that sentence. Typically it changed nothing at all, or it undid a later change instead. Haiku managed 2 of 6 in an earlier run and 0 of 6 in the final one. Most of the long-chain failures come from the same place, since three of the four long chains contain that turn.

gpt-oss-20b is the outlier. It passed all six of those scenarios and dropped a few easy ones instead. It and GPT-5.4 mini both scored 30 out of 40 in that run, with almost opposite profiles.

Reasoning or not, same model

Grok 4.20 reasoning scored 1.00 and the non-reasoning version 0.75. In my local runs the non-reasoning version got 0 of 6 on the earliest-change scenarios every time, and the reasoning version's only earlier miss was a scenario I later fixed because the wording was ambiguous. That's one model pair and one run each, and I picked the pair after I'd seen early results. So I'm treating it as an interesting lead and I'm not drawing a general conclusion about reasoning models from it.

A pass count hides how a model fails

Haiku fails 11 of 40 scenarios but moves the fewest unrelated settings (a mean change radius of 0.075). GPT-5.4 mini fails 10 and moves the most (0.325). Grok non-reasoning sits at 0.125 and gpt-oss-20b at 0.200. A single score can't tell you whether a model's mistakes are contained or spread across the whole spec.

Many of my "model failures" were my own wording

I read the transcripts before blaming any model, and four wording problems turned up. None of them changed the oracle, the scoring or the prompts, and I logged each fix.

"Take back whatever I said about how long each file may take." Gemini 3.7 Flash set the timeout to unspecified instead of restoring 30 seconds. My opening spec also mentioned timeouts, so "everything I said about them" is a fair reading. I reworded it to "Undo the change I made to…".
"Drop the header row." My instructions told models to use unspecified for requirements the user has dropped. The same scenario passed once and failed once on identical text. That turned out to be the pattern every time: a scenario that flips between pass and fail is usually ambiguous.
"I no longer care about a time limit per file." Claude Haiku and Grok non-reasoning answered with timeout='none' in all four fresh runs. none is a legal value meaning no limit, so both readings are fair.
"Read JSON files instead of CSV." This is the story from the top. In 5 of 9 reruns, Sonnet 5, Grok reasoning and gpt-oss-20b all set the delimiter and header row to unspecified, and my oracle, which only knew about three couplings, scored sensible behaviour as collateral damage. I removed the undeclared coupling from the scenario instead of adding a fourth rule.

If you build a benchmark with an exact answer key, my advice is this: when a model seems to break something, check whether a reasonable reader of your prompt would have done the same.

Final-state scoring hides blips

One gpt-oss-20b run returned unspecified for 18 of the 20 settings in turns 1 to 3, then recovered by turn 4. The final state was correct, so a final-state score would never show it. Only the first-divergence turn did.

The top is saturated

Three models scored 1.00, so ButterflyBench separates mid-range models better than strong ones.

What I'd measure next

Paraphrases of the earliest-change instruction. All ten scenarios that contain it use the same sentence, so I can't yet tell "can't track history" from "that wording is hard".
Repeated runs for every model, to put error bars on the leaderboard.
Longer chains and a version that resets the state each turn, to separate failing early from failing late.
Code as the artifact. ButterflyBench tracks a structured spec. It doesn't test whether generated code survives an edit.

Limitations

It tests tracking of a structured spec, not collateral damage inside code. It's a small public benchmark, so models could be trained on it. And the oracle encodes only the three couplings I stated.

If you're building on Kaggle Benchmarks

Three things cost me time. Nested evaluations force max_attempts=1, so retry inside your own task, otherwise one provider hiccup shows up as "Error" for a whole model. An expensive model failed with a 403 ("estimated cost exceeds your available quota") until I capped its output tokens through extra_api_params. And the main task's docstring becomes its description, which must be 255 characters or fewer.

My Benchmark

Benchmark on Kaggle: https://www.kaggle.com/benchmarks/emmimalalexander/butterflybench
Task and leaderboard: https://www.kaggle.com/benchmarks/tasks/emmimalalexander/butterflybench
Notebook (oracle, scoring and all 40 scenarios): https://www.kaggle.com/code/emmimalalexander/butterflybench

Retrieval Isn't Enough — I Built a Claim Relationship Resolver

Emmimal P Alexander — Wed, 30 Sep 2026 07:52:00 +0000

Claim Relationship Resolver

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

I built a Claim Relationship Resolver, a deterministic, pure-Python agent using only the standard library and no LLM API. It answers questions from structured claims stored in Sanity, but instead of simply retrieving a matching document, it determines how the retrieved claims relate to each other before producing an answer. The agent takes a structured question, retrieves the relevant claims through Sanity Context MCP, applies the relationship rules, and returns a typed result rather than generating an answer from retrieved text.

The idea started from one distinction: two claims can look different without actually disagreeing. A pricing limit of 500 for new accounts and 100 for legacy accounts isn't necessarily a contradiction, it can just be a scope difference. But two claims with the same applicable scope that disagree, with no relationship resolving them, represent a genuine conflict. And a claim explicitly superseded by another claim shouldn't remain current simply because it's still sitting in the knowledge base.

A retrieval system can return those claims. The missing layer is deciding what relationship they have.

My resolver classifies each question into one of five outcomes:

SUPPORTED — one applicable claim supports the answer.
CONTEXTUAL — different valid answers apply to different scopes.
SUPERSEDED — an explicit supersedes relationship makes an older claim stale.
CONFLICTING — applicable claims for the same scope disagree and no relationship resolves the difference.
INSUFFICIENT — no eligible claim exists for the question.

The rules are frozen and documented before evaluation. There's no "newest wins" heuristic and no source-authority ranking. A claim becomes stale only through an explicit supersedes relationship.

To evaluate the system, I built:

A 404-question held-out benchmark generated from a fixed seed, with ground truth determined independently by how each test case was constructed, not by running the resolver.
A blind 36-question audit, where I manually labeled the cases from the frozen rules before inspecting the generated answers: 36/36 agreement.
Three comparison baselines: a retrieval-only BM25 baseline, newest claim wins, and newest claim wins within the matching scope.
Two real-content datasets: 36 real TDS Contributor Portal articles and the 20 most recent pages from my EmiTechLogic sitemap, run through the same resolver and baselines with no synthetic benchmark data involved.

Held-out results

On the 380 headline questions in the held-out benchmark:

System	Correct	Confidently wrong	Missed conflicts
Claim Relationship Resolver	380/380	0/380	0/50
B+scope	276/380	38/380	50/50
B_newest	176/380	180/380	50/50
A_retrieval	125/380	255/380	50/50

The 404 questions come from 240 claim clusters, so they aren't independent observations. I report the cluster count explicitly rather than treating the 404 questions as 404 unrelated experiments. The remaining 24 questions are Tier-2 cases outside the headline accuracy calculation, and the resolver correctly returns unsupported_case for all 24 rather than guessing (that's the 380 + 24 = 404).

The resolver produced 0 false conflicts among the 330 non-conflict headline questions.

Real-Content Demo

The benchmark tests the relationship rules systematically. The real-content demo shows what happens when the same resolver is pointed at actual content.

The real-content build contains 149 documents: 57 scopes and 92 claims, drawn from 36 real TDS articles and 20 recent EmiTechLogic blog pages.

For a specific TDS article where no eligible claim exists, the resolver returns INSUFFICIENT rather than borrowing a value from another article. The baselines return values like submitted or draft instead.

The clearest example is a portfolio-wide question. Ask "what's the status of my whole TDS portfolio," and the resolver reports:

CONTEXTUAL across 34 scopes

rather than collapsing the portfolio into one status. The newest-value baseline answers submitted, and the retrieval baseline answers published, each picking a single value that's only true for one article.

The EmiTechLogic sitemap produces the same pattern: a blog-wide query spans 20 scopes, and the baselines collapse those multiple scoped claims into a single answer.

The real-content dataset intentionally contains no SUPERSEDED or CONFLICTING cases. Those relationship types are evaluated in the controlled held-out benchmark, not here.

Demo

https://youtu.be/35ab7M0CmBI

The demo is a silent walkthrough: the Sanity Studio data, terminal output, and benchmark results show the complete flow.

Sanity Studio — a real claim document: subject, attribute, value, scope reference, and an explicit supersedes relationship.
A live run against my EmiTechLogic blog data. Ask about the whole blog and the resolver reports CONTEXTUAL across 20 scopes. Ask about a page with no eligible claim and it returns INSUFFICIENT. Meanwhile the baselines collapse the scoped claims into a single answer regardless.
The held-out benchmark result, run live against Sanity: 380/380 for the resolver, zero false conflicts and zero missed conflicts, against 276/380, 176/380, and 125/380 for the three baselines.

There's also a static, no-setup version of this: demo.html in the repo (below) is a self-contained page with the same real examples, viewable by opening the file directly in any browser, no server or credentials needed.

Sanity isn't failing to retrieve the information here. It provides the structured claims; the resolver decides how those claims relate before an answer comes out.

Code

Repository: https://github.com/Emmimal/claim-relationship-resolver

The repository contains:

resolver.py — the frozen resolver logic
RESOLVER_RULES.md — the frozen rules and amendments log, including two bugs I found and fixed during live testing
heldout/ — the 404-question benchmark and blind audit materials
real_content/ — the real datasets and demonstration script
demo.html — a static, self-contained demo page with real examples, no server needed
compare.py — runs the resolver and baselines against local, mock, or live Sanity data and checks local/live parity

compare.py --source local and --source mock reproduce the exact same results with no Sanity credentials needed, so the benchmark is checkable without any setup. --source live re-runs everything against the actual Sanity Context MCP endpoint.

How I Used Sanity

I used Sanity Context in GROQ mode rather than Knowledge Base mode, because the data consists of structured facts: subject, attribute, value, scope, version, effective date, and explicit supersedes relationships.

That structure is central to the project. It's what lets the agent reason about relationships between claims instead of treating retrieved text as isolated answers.

Why I used GROQ mode

I used a Sanity Context MCP endpoint backed directly by my structured dataset and queried it through the groq_query tool.

That choice follows the shape of the data. My claims aren't primarily prose documents that need semantic distillation. They're typed records with fields like subject, attribute, value, scope, version, effectiveFrom, and supersedes, and the resolver needs those fields intact because they're part of the relationship rules.

The challenge supports pointing an agent at a full dataset through Context MCP as an alternative to the Knowledge Base beta's document limit. I chose the dataset route because this resolver needs exact matches on subject and attribute, followed by deterministic relationship logic. I query the Context MCP groq_query tool directly rather than using semantic similarity for retrieval.

There's no LLM anywhere in the retrieval or resolution loop. Sanity provides the structured content through Context MCP; the resolver determines how the returned claims relate.

This also keeps the retrieval boundary explicit: Sanity answers "which structured claims match this subject and attribute?" and the Python resolver answers "what relationship do those claims have?"

I also discovered and fixed a subject-isolation bug during live testing: an early query could retrieve unrelated claims when multiple subjects shared the dataset. The fix and how I verified it are documented in RESOLVER_RULES.md.

Schema

There are two document types:

scope — hierarchical scopes connected through a parent reference, such as enterprise under all.
claim — a structured claim containing its subject, attribute, value, scope, version, effective date, and an optional supersedes array containing {claim, inScope} references.

The schema was deployed from a Sanity Studio project using sanity schema deploy.

Retrieval

The Python client talks to the Sanity Context MCP endpoint over JSON-RPC and calls the groq_query tool, using two query shapes: fetch claims for the requested subject and attribute, and fetch the scope hierarchy needed to determine containment.

There's no LLM involved in this retrieval or resolution loop. The query inputs come directly from the structured question fields.

Resolution

After retrieval, the resolver applies the frozen rules in sequence:

Temporal validity — is the claim effective on or before the question's as-of date?
Scope containment — does the claim apply to the requested scope, and does a narrower applicable scope take precedence over a broader one?
Explicit supersession — does an explicit relationship replace an older claim, and does that relationship apply to the requested scope?
Relationship classification — do the remaining claims produce a supported answer, contextual answers, a genuine conflict, or insufficient evidence?

Missing metadata is never silently guessed. A missing scope isn't assumed to mean global scope, and a missing effective date doesn't automatically make a claim eligible.

Sanity Project for Submission

Project ID: ouvupih6
Project Name: Claim Relationship Resolver
Dataset: production
Organization ID: o4oimb7tz
Dataset URL: https://ouvupih6.apicdn.sanity.io/v2024-01-01/data/query/production?query=*[_type=="claim"]
Studio URL: https://claim-relationship-resolver-emitechlogic.sanity.studio/

SHAP Is Not Production-Ready — And We Need to Stop Pretending It Is

Emmimal P Alexander — Wed, 15 Apr 2026 05:18:12 +0000

SHAP Is Not Production-Ready — And We Need to Stop Pretending It Is

This might be unpopular, but it needs to be said:

Most explainable AI setups are fundamentally broken in production.

Not because they’re inaccurate.

Because they’re too slow, inconsistent, and disconnected from the model itself.

The uncomfortable reality

In a real-time fraud system, I tested SHAP (KernelExplainer):

~30 ms per prediction
Run it twice → different explanations
Requires background data + sampling

Now ask yourself:

Would you ship a system where:

explanations change every time
latency is unpredictable
and audit logs aren’t deterministic?

Because that’s exactly what we’re doing.

The core mistake

We’ve accepted this architecture:

Model → Prediction → Separate Explainer → Explanation

That separation is the problem.

You’re trying to explain a deterministic system with a stochastic process… and calling it reliable.

I tried something different

Instead of improving SHAP…

I removed it.

Built a model where:

symbolic rules run alongside the neural network
explanations are generated inside the forward pass

No post-processing. No sampling.

What happened

0.9 ms per prediction + explanation
33× faster than SHAP
Deterministic outputs
Same fraud recall as the baseline

The explanation is no longer something you compute later.

It’s something the model already knows.

The bigger point

We don’t have an explainability problem.

We have an architecture problem.

As long as explanations are:

bolted on
slow
and probabilistic

they will never work in systems that need:

real-time decisions
auditability
and consistency

Full experiment (code + benchmark)

I documented everything here:

👉 Explainable AI in Production: A Neuro-Symbolic Model for Real-Time Fraud Detection

If you're building real systems, this is the question:

Do you want explanations that look good…

or explanations you can actually deploy?

Why Python's sorted() Is Safer Than list.sort() in Production Systems

Emmimal P Alexander — Wed, 04 Mar 2026 06:56:50 +0000

Every Python tutorial puts sorted() and list.sort() side by side and says something like: "sort() modifies in place, sorted() returns a new list." That is correct. And for a script that runs once and exits, it is probably enough.

But if you write backend services — where request handlers share state, where functions receive lists as arguments, where a cache holds data that multiple parts of the codebase read — this explanation misses the details that cause real incidents.

This article covers those details. By the end you will understand exactly what CPython does in memory during each operation, what the GIL actually protects during a sort (and where a popular explanation gets it wrong), and why the mutation behaviour of list.sort() is a consistent source of bugs that are hard to find.

The One-Line Difference That Misleads People

nums = [3, 1, 4, 1, 5]

# list.sort() — modifies the list, returns None
nums.sort()
print(nums)          # [1, 1, 3, 4, 5]

# sorted() — leaves the input alone, returns a new list
result = sorted(nums)
print(nums)          # [1, 1, 3, 4, 5] — untouched
print(result)        # [1, 1, 3, 4, 5] — new object

In isolation this looks like a minor stylistic choice. In a service, it is not.

The Mutation Problem

When you call my_list.sort(), Python rearranges element pointers inside the original list object. Every variable in your program that holds a reference to that same object immediately sees the new order. No copy is made. No warning is raised. The data just changes.

In a linear script this does not matter. In a service where a list travels from a cache into a handler into a utility function, it creates a category of bug that does not crash — it just produces subtly wrong output.

The aliasing pattern that shows up constantly

raw_orders = [5, 2, 9, 1, 7]
audit_trail = raw_orders        # looks like a rename — it is an alias

def process(order_ids):
    order_ids.sort()            # mutates raw_orders silently
    return order_ids

result = process(raw_orders)

print(result)       # [1, 2, 5, 7, 9]  ← correct output
print(audit_trail)  # [1, 2, 5, 7, 9]  ← insertion order gone
print(raw_orders)   # [1, 2, 5, 7, 9]  ← same object, same damage

The audit trail was supposed to record arrival order. It is now sorted. No crash occurred. The data just silently lost its shape.

The fix is one word:

def process(order_ids):
    return sorted(order_ids)    # new list, nothing mutated

What CPython Does in Memory

Understanding why the mutation reaches all aliases requires a quick look at how Python represents a list internally.

CPython stores each list as a struct called PyListObject. It holds a pointer to an array of pointers (ob_item) — one pointer per element. The actual element objects live elsewhere in memory.

/* CPython — Objects/listobject.c (simplified) */
typedef struct {
    PyObject_VAR_HEAD
    PyObject **ob_item;    /* array of pointers to elements */
    Py_ssize_t allocated;  /* capacity */
} PyListObject;

When list.sort() runs: Timsort rearranges the pointers inside ob_item. The integer or string objects on the heap do not move at all. Because every Python name that refers to this list holds the same memory address of the PyListObject, they all observe that rearrangement the instant it finishes.

When sorted() runs: It creates a brand new PyListObject, copies the element pointers into it, and sorts that new object. The original PyListObject's ob_item is never touched.

Before any sort:
  original  ──►  PyListObject @ 0x7f3a  [5, 2, 9, 1]
  alias     ──►  PyListObject @ 0x7f3a  [5, 2, 9, 1]

After alias.sort():
  original  ──►  PyListObject @ 0x7f3a  [1, 2, 5, 9]  MUTATED
  alias     ──►  PyListObject @ 0x7f3a  [1, 2, 5, 9]  same object

After sorted(original):
  original  ──►  PyListObject @ 0x7f3a  [5, 2, 9, 1]  untouched
  alias     ──►  PyListObject @ 0x7f3a  [5, 2, 9, 1]  untouched
  result    ──►  PyListObject @ 0x8b1c  [1, 2, 5, 9]  new object

You can verify the object identity yourself with id():

a = [3, 1, 2]
b = a

b.sort()
print(id(a) == id(b))   # True — one object, two names

a = [3, 1, 2]
b = a
c = sorted(a)
print(id(a) == id(c))   # False — two independent objects

The GIL and list.sort() — Correcting a Widespread Claim

Many articles — including a previous version of content on this topic — state that "CPython's Timsort drops the GIL at internal checkpoints, allowing other threads to see a partially sorted list."

That claim is not accurate for standard CPython, and it is worth being precise.

What actually happens

Without a Python key function: When you call list.sort() with no key, or with a C-level key like operator.attrgetter, the entire sort runs as a single C function call. The GIL is held throughout. No other Python thread runs during that call. As a CPython implementation detail, the list appears empty to other threads while the sort is in progress — not partially sorted, not torn. The final sorted state becomes visible all at once when the sort completes.

With a Python key function: When you pass a Python lambda — key=lambda x: x.score — every comparison calls that lambda, which re-enters Python bytecode execution. The GIL can release between those calls. During those windows, another thread can read the list in an intermediate rearrangement state. So partially sorted views are possible — but only when a Python-level key function is involved.

import threading, time

shared = list(range(500, 0, -1))

def reader():
    time.sleep(0.001)
    snap = shared[:]          # what does this thread see?
    print(f"Reader saw {len(snap)} items")

# Case 1: No key — GIL held, reader sees empty list or final result
t1 = threading.Thread(target=reader)
t2 = threading.Thread(target=lambda: shared.sort())
t1.start(); t2.start()
t1.join(); t2.join()

# Case 2: Python lambda key — GIL releases between comparisons
shared = list(range(500, 0, -1))
t3 = threading.Thread(target=reader)
t4 = threading.Thread(target=lambda: shared.sort(key=lambda x: x))
t3.start(); t4.start()
t3.join(); t4.join()

But the GIL is not the real problem

Whether the GIL drops during the sort or not, the end result is the same: once sort() finishes, the list is permanently reordered. Every reference to that object — in every thread, in every function, in every cache — immediately sees the new state. No notification, no flag, no synchronisation point.

That permanent shared mutation is the actual danger, not the torn-read scenario.

A Real Cache Corruption Pattern

Here is the pattern that causes multi-week debugging sessions.

# cache.py
_store = {}

def get_products():
    if 'products' not in _store:
        _store['products'] = [
            {'name': 'Pen',   'price': 1.50,  'order': 1},
            {'name': 'Desk',  'price': 299.0, 'order': 2},
            {'name': 'Chair', 'price': 189.0, 'order': 3},
            {'name': 'Lamp',  'price': 45.0,  'order': 4},
        ]
    return _store['products']    # returns the actual cache object

# handlers.py

def handler_top_by_price():
    products = get_products()
    # BUG: sorts the shared cache object in place
    products.sort(key=lambda p: p['price'], reverse=True)
    return [p['name'] for p in products]

def handler_listing():
    products = get_products()
    return [p['name'] for p in products]    # expects insertion order

# Simulate requests arriving in this order

print(handler_listing())
# ['Pen', 'Desk', 'Chair', 'Lamp']  ← correct

print(handler_top_by_price())
# ['Desk', 'Chair', 'Lamp', 'Pen']  ← correct output

print(handler_listing())
# ['Desk', 'Chair', 'Lamp', 'Pen']  ← WRONG
# Cache is permanently reordered. Every future request is affected.
# No exception. No log entry. Just wrong data.

The fix is one word — .sort() becomes sorted():

def handler_top_by_price():
    products = get_products()
    top = sorted(products, key=lambda p: p['price'], reverse=True)
    return [p['name'] for p in top]

# Cache is now untouched. handler_listing() always returns insertion order.

The investigation for this class of bug typically takes much longer than the fix. The symptom — data in the wrong order — points toward the algorithm, the database query, or the cache expiry policy. The sort call in a request handler is usually the last place anyone looks.

Pipeline Safety

One structural advantage of sorted() that gets overlooked: functions that do not mutate their inputs are independently testable and safely composable.

def filter_active(users):
    return [u for u in users if u['active']]

def rank_by_score(users):
    return sorted(users, key=lambda u: u['score'], reverse=True)

def take_top(users, n=10):
    return users[:n]

# all_users is untouched through every stage.
result = take_top(rank_by_score(filter_active(all_users)))

With sorted(), each function in the chain can be tested like this:

def test_rank_does_not_mutate_input():
    users = [{'score': 82}, {'score': 91}, {'score': 74}]
    before = users[:]
    rank_by_score(users)
    assert users == before    # passes with sorted(), fails with .sort()

This is not possible when rank_by_score uses .sort() internally — the test fixture is mutated by the call, and running the same test twice on the same data produces different results the second time.

Performance — The Honest Picture

sorted() is a little slower because it allocates a new list before sorting. The table below shows approximate timings on CPython 3.12.

List size	list.sort()	sorted()	Overhead
100 elements	0.8 µs	1.1 µs	+38%
1,000 elements	8.5 µs	10.2 µs	+20%
10,000 elements	28 µs	31 µs	+11%
100,000 elements	310 µs	345 µs	+11%
1,000,000 elements	3.8 ms	4.2 ms	+11%

A few things to note:

The percentage overhead is largest at small list sizes where the absolute difference is trivially small (0.3 µs).
At large list sizes where the absolute difference is measurable (40 ms at 1M elements), sorting that many items in a request handler is itself the architectural problem — the sort belongs at the database level.
A single database round-trip takes roughly 1 ms. The allocation cost of sorted() on a 10,000-element list is 3 µs. The comparison is not close.

The allocation cost of sorted() does not compound across refactors. The mutation risk of .sort() does.

You can run this benchmark yourself with the script in the companion GitHub repository:

# benchmark.py
import timeit, random

def run(n, iterations=300):
    data = random.sample(range(n * 10), n)
    t_sort   = timeit.timeit('lst[:].sort()',
                              setup=f'lst={data}', number=iterations) / iterations * 1e6
    t_sorted = timeit.timeit('sorted(lst)',
                              setup=f'lst={data}', number=iterations) / iterations * 1e6
    delta = ((t_sorted - t_sort) / t_sort) * 100
    print(f"n={n:>9,}  sort={t_sort:>8.2f}µs  sorted={t_sorted:>8.2f}µs  overhead={delta:>+.1f}%")

for n in [100, 1_000, 10_000, 100_000, 1_000_000]:
    run(n)

sorted() Accepts Any Iterable — list.sort() Does Not

A practical difference that matters during refactoring: sorted() works on any object that implements the iterator protocol. list.sort() is a method on list objects only.

nums_tuple = (3, 1, 4, 1, 5)
nums_set   = {3, 1, 4, 1, 5}
nums_gen   = (x for x in range(5, 0, -1))

sorted(nums_tuple)   # [1, 1, 3, 4, 5]  ← works
sorted(nums_set)     # [1, 3, 4, 5]     ← works (deduped by set)
sorted(nums_gen)     # [1, 2, 3, 4, 5]  ← works

nums_tuple.sort()    # AttributeError: 'tuple' has no attribute 'sort'
nums_set.sort()      # AttributeError: 'set' has no attribute 'sort'
nums_gen.sort()      # AttributeError: 'generator' has no attribute 'sort'

If your data source changes from a list to a generator or a query result during refactoring, sorted() keeps working. .sort() calls fail at runtime.

When list.sort() Is the Right Choice

list.sort() is appropriate when all of the following hold:

You built the list in the current scope and no other reference to it exists anywhere — not a parameter, not from a cache, not assigned to another name.
You will not pass this list downstream — no function that calls this one will receive the list after the sort.
You have profiled and measured that the allocation cost of sorted() is a real bottleneck in your specific workload. Not assumed — measured with a profiler like cProfile or py-spy.

In most backend service code, all three conditions are rarely true at the same time.

# This is fine — you built it, you own it, no external references
def get_report_rows(data):
    rows = [transform(d) for d in data]   # new list, built here
    rows.sort(key=lambda r: r['date'])     # sole owner — acceptable
    return rows

# This is not fine — you received it, you do not own it
def process(records):
    records.sort()    # mutates the caller's data
    return records

Antipatterns Worth Knowing

# 1. Sorting then copying — worst of both worlds
def get_sorted(items):
    items.sort()            # mutates caller
    return sorted(items)   # pays allocation cost anyway
# Use: return sorted(items)  — one call, no mutation

# 2. Trusting the return value of sort()
result = items.sort()      # result is None
print(result[0])           # TypeError: 'NoneType' is not subscriptable

# 3. Manual copy + sort — noisier than sorted()
copy = items[:]
copy.sort()
return copy
# Use: return sorted(items)  — identical result, one line

# 4. Sorting a parameter without the caller knowing
def rank(items, key_fn):
    items.sort(key=key_fn)  # caller's list is now sorted
    return items            # looks like it just returns, hides the mutation

Both Functions Are Stable — This Is Guaranteed

Both list.sort() and sorted() use Timsort internally. Both are guaranteed stable by the Python language specification — not just CPython's implementation. Equal elements maintain their original relative order.

records = [
    {'dept': 'Engineering', 'hire_date': '2022-03'},
    {'dept': 'Design',      'hire_date': '2021-07'},
    {'dept': 'Engineering', 'hire_date': '2020-11'},
]

# After sorting by department, the two Engineering records appear
# in the same relative order they had in the original list.
sorted_records = sorted(records, key=lambda r: r['dept'])
# Design / Engineering(2022-03) / Engineering(2020-11)
# → Design / Engineering(2020-11) / Engineering(2022-03) — stable

This guarantee holds across CPython, PyPy, and any other compliant Python implementation. It has been part of the language specification since Python 2.2.

The Full Test Suite

Here is a test file you can drop into any project to verify sorting behaviour:

# test_sort_safety.py
import copy
import unittest

def rank_buggy(items):
    items.sort(key=lambda x: x['v'])
    return items

def rank_safe(items):
    return sorted(items, key=lambda x: x['v'])


class TestSortSafety(unittest.TestCase):

    def setUp(self):
        self.data = [{'v': 3}, {'v': 1}, {'v': 4}, {'v': 1}, {'v': 5}]
        self.snapshot = copy.deepcopy(self.data)

    def test_sort_mutates_input(self):
        rank_buggy(self.data)
        # Input was changed — this assertion fails, proving the mutation
        self.assertNotEqual(self.data, self.snapshot,
                            "rank_buggy() did not mutate input")

    def test_sorted_preserves_input(self):
        rank_safe(self.data)
        self.assertEqual(self.data, self.snapshot,
                         "rank_safe() mutated the input")

    def test_sorted_returns_new_object(self):
        result = rank_safe(self.data)
        self.assertIsNot(result, self.data)

    def test_sorted_produces_correct_order(self):
        result = rank_safe(self.data)
        vals = [d['v'] for d in result]
        self.assertEqual(vals, sorted(vals))

    def test_stable_sort_preserves_relative_order(self):
        items = [{'v': 1, 'pos': 'first'}, {'v': 2}, {'v': 1, 'pos': 'second'}]
        result = rank_safe(items)
        # Equal elements maintain original order
        equals = [r for r in result if r['v'] == 1]
        self.assertEqual(equals[0].get('pos'), 'first')
        self.assertEqual(equals[1].get('pos'), 'second')

    def test_same_input_gives_same_output_every_time(self):
        r1 = rank_safe(self.data)
        r2 = rank_safe(self.data)
        self.assertEqual([d['v'] for d in r1], [d['v'] for d in r2])


if __name__ == '__main__':
    unittest.main()

Run it:

python -m pytest test_sort_safety.py -v

The first test (test_sort_mutates_input) is designed to fail — it proves the mutation happened. The rest should all pass.

Quick Reference

# The rule in one place

# DEFAULT: always safe, works on any iterable
result = sorted(collection, key=..., reverse=...)

# EXCEPTION: only when you built the list here,
# no other references exist, and you have measured a bottleneck
your_list.sort(key=..., reverse=...)

# NEVER:
result = your_list.sort()    # result is None

What to Read Next

The full article on emitechlogic.com includes interactive visualisations you cannot see in a Markdown post:

A live mutation visualiser — click a button and watch all aliased variables change simultaneously
A CPython memory diagram with tabs showing the ob_item pointer array before and after each operation
A thread simulator that replays the shared-cache corruption event, step by step with timestamps
An animated benchmark chart with click-to-expand engineering context for each list size
A 10-question quiz with per-answer explanations and a final score
A decision flowchart with five questions that walk you to the correct function for your situation

The companion GitHub repository has all code from this article in runnable form — benchmark script, full test suite, cache corruption demo, and GIL behaviour examples — all with no external dependencies.

Master Monotonic Sequences in Python: 7 Methods, Edge Cases & Interview Tips

Emmimal P Alexander — Tue, 24 Feb 2026 04:04:53 +0000

If you've ever needed to verify if a list of stock prices, sensor readings, or ML training losses is trending consistently in one direction, checking for monotonicity is key. This is a common task in data pipelines, time-series analysis, and even tech interviews (shoutout to LeetCode 896!).

What Is a Monotonic Sequence?

A monotonic sequence is one that is entirely non-decreasing or entirely non-increasing.

It never changes direction — no zigzagging.

Main Types

Non-decreasing

Each element ≤ next element

Allows equals

Example: [1, 2, 2, 3, 5]
Strictly increasing

Each element < next element

No equals allowed

Example: [1, 3, 4, 8]
Non-increasing

Each element ≥ next element

Allows equals

Example: [9, 7, 7, 4, 2]
Strictly decreasing

Each element > next element

No equals allowed

Example: [10, 8, 5, 1]

Most algorithm problems use non-strict (≤ or ≥) unless they explicitly say “strictly”.

Quick Comparison Table

Sequence	Non-Decreasing	Strictly Increasing	Non-Increasing	Strictly Decreasing
`[1, 2, 2, 3]`	✓	✗	✗	✗
`[1, 2, 3, 4]`	✓	✓	✗	✗
`[5, 4, 4, 1]`	✗	✗	✓	✗
`[5, 5, 5, 5]`	✓	✗	✓	✗
`[]` (empty)	✓	✓	✓	✓
`[42]` (single)	✓	✓	✓	✓

Important Edge Cases

Empty list [] → monotonic (vacuously true)
Single element [x] → always monotonic
All equal [7,7,7,7] → both non-decreasing and non-increasing
Floating point values → dangerous for strict checks 0.1 + 0.2 == 0.3 is false in most languages → Use math.isclose() or small epsilon
Negative numbers → handled normally
Mixed types ([1, "2"]) → usually raises error

Floating-point strict check tip (Python example)

from math import isclose

def is_strictly_increasing_float(seq, rel_tol=1e-9, abs_tol=1e-12):
    return all(x < y and not isclose(x, y, rel_tol=rel_tol, abs_tol=abs_tol) for x, y in zip(seq, seq[1:]))

7 Practical Methods to Check Monotonicity

All methods below check for non-strict monotonicity by default

→ sequence is either non-decreasing (≤) or non-increasing (≥)

Most production code and interviews expect this behavior unless “strictly” is specified.

1. Simple Loop with Flags (O(n) time, O(1) space)

Great for interviews — very explicit and easy to explain.

def is_monotonic(nums):
    if len(nums) <= 1:
        return True
    increasing = decreasing = True
    for i in range(len(nums) - 1):
        if nums[i] > nums[i + 1]:
            increasing = False
        if nums[i] < nums[i + 1]:
            decreasing = False
    return increasing or decreasing

2. Using all() with Early Exit (O(n) time, O(1) space)

Pythonic, very readable, and now optimized with early exit so it stops as soon as it finds a violation — much better for large lists that are not monotonic.

Classic two-pass version (no early exit)

def is_monotonic(nums):
    return (all(nums[i] <= nums[i+1] for i in range(len(nums)-1)) or
            all(nums[i] >= nums[i+1] for i in range(len(nums)-1)))

3. zip() for Pairwise Comparison (O(n) time, ~O(n) space)

One of the cleanest and most Pythonic ways to check monotonicity.

We use zip(arr, arr[1:]) to create consecutive pairs without manually handling indices.

Basic version (two logical passes)

def is_monotonic(nums):
    return (all(x <= y for x, y in zip(nums, nums[1:])) or
            all(x >= y for x, y in zip(nums, nums[1:])))

4. sorted() Comparison (O(n log n) time, O(n) space)

This is one of the simplest and most intuitive ways to check monotonicity — especially useful when:

You're prototyping quickly
The input size is small (n ≤ ~10⁴–10⁵)
You want the shortest, most obvious code possible
You're explaining the concept to beginners

However, avoid this in production or in coding interviews when performance matters, because sorting is unnecessary work when we only need to check order.

Classic One-Liner Version

def is_monotonic(nums):
    return nums == sorted(nums) or nums == sorted(nums, reverse=True)

5. NumPy for Data Pros (O(n) time, O(n) space)

Vectorized, extremely fast on large arrays, perfect when you're already working in a NumPy / pandas / data-science environment.

This is the go-to method in scientific computing, machine learning pipelines, time-series analysis, and any situation where your data is already a NumPy array (or easily convertible).

Core Implementation

import numpy as np

def is_monotonic(arr):
    """
    Check if array is monotonic (non-decreasing or non-increasing) using NumPy.
    Fast for large arrays thanks to vectorized operations.
    """
    if len(arr) <= 1:
        return True

    # Convert to numpy array if it isn't already
    arr = np.asarray(arr)

    # Compute differences in one vectorized operation
    diff = np.diff(arr)

    # Check if all differences are non-negative OR all are non-positive
    return np.all(diff >= 0) or np.all(diff <= 0)

6. itertools.pairwise() (Python 3.10+, O(n) time, O(1) space)

The modern, cleanest iterator-based approach — available since Python 3.10.

No list slicing, no manual indexing, no extra memory for pairs — pure lazy iteration.

This is many people's current go-to when writing new code targeting recent Python versions.

Basic Elegant Version

from itertools import pairwise

def is_monotonic(nums):
    if len(nums) <= 1:
        return True
    return (all(x <= y for x, y in pairwise(nums)) or
            all(x >= y for x, y in pairwise(nums)))

7. One-Pass Direction Detection (O(n) time, O(1) space)

This is widely considered the interview favorite and one of the cleanest production-ready solutions.

Single pass through the array
Constant extra space
Early exit as soon as direction conflict is detected
Gracefully handles leading equal elements (plateaus)
Works for both non-strict increasing and decreasing

Classic & Optimized Version

def is_monotonic(nums):
    if len(nums) <= 1:
        return True

    direction = 0  # 0 = unknown, 1 = increasing, -1 = decreasing

    for i in range(len(nums) - 1):
        if nums[i] < nums[i + 1]:
            if direction == 0:
                direction = 1
            elif direction == -1:
                return False
        elif nums[i] > nums[i + 1]:
            if direction == 0:
                direction = -1
            elif direction == 1:
                return False
        # else: equal → no change to direction (continue)

    return True

Performance Breakdown

Here's a concise comparison of the 7 methods we covered, focusing on the key performance and practical aspects.

Method	Time	Space	Early Exit?	Best For	Notes / Trade-offs
1. Simple Loop + Flags	O(n)	O(1)	Yes	Interviews, debugging, explanation	Very explicit, easy to modify for strict mode
2. all() / Two-Pass	O(n)	O(1)	Partial	Clean, readable code	Always full passes unless using for-loop break
3. zip() Pairwise	O(n)	~O(1)	Partial	Readability, Pythonic style	zip is lazy → low memory, but two passes common
4. sorted() Comparison	O(n log n)	O(n)	No	Quick prototyping, teaching	~30× slower on large data — avoid in prod
5. NumPy diff	O(n)	O(n)	No	Large arrays, data science	Fastest on big numeric data (vectorized)
6. itertools.pairwise()	O(n)	O(1)	Partial	Modern Python (3.10+), clean code	Iterator magic — zero-copy pairs
7. Direction Detection	O(n)	O(1)	Yes	Advanced interviews, production	Single pass + early exit = best real-world perf

Real-World Benchmarks (approx. on 1 million elements, Python 3.11–3.12, typical laptop)

Pure O(n) methods (loops, zip, pairwise, direction detection): ~20–35 ms
NumPy diff + all(): ~8–15 ms (often fastest due to vectorization)
sorted() comparison: ~700–1000 ms (~30–50× slower)

Early exit methods (especially #1 Flags, #7 Direction Detection, and single-pass violation checks) shine on messy / non-monotonic data:

Zigzag early → return in < 1 ms
Mostly monotonic but fails late → still full pass, but average case much better than always-full-pass methods

Quick Decision Guide

Scenario	Recommended Method(s)
Coding interview	#7 Direction Detection or #1 Flags
Clean & short production code	#6 pairwise() or #2 all()
Already using NumPy / pandas	#5 NumPy diff
Python 3.10+ and want modern style	#6 itertools.pairwise
Quick script / notebook / teaching	#4 sorted() (then optimize if needed)
Need strict monotonicity	Modify #7 or #6 with < / > checks
Float data with precision issues	Add tolerances (#5 NumPy best)
Very large arrays (>10M elements)	#5 NumPy or #7 with early exit

Bottom line

→ Method 7 (Direction Detection) or Method 6 (pairwise + violation check) is the sweet spot for general-purpose, interview-ready, production-grade code.

→ Switch to NumPy the moment you're dealing with serious numerical data volumes.

Interview Hacks & Common Pitfalls

Clarify strictness: Ask if equals are allowed (non-strict ≤/≥ vs strict < />).
Streaming adaptation: Use a single prev variable to handle generators / online data.
Avoid sorted(): Interviewers want O(n) time — mention it only to show understanding, then pivot to linear solution.
Pitfalls to avoid:
- Wrong loop range → IndexError (use range(1, len(arr)) or zip/pairwise)
- Ignoring / mishandling equal elements
- Not handling edge cases: empty list [], single element [x], all equal [5,5,5]
- Floating-point precision issues (direct comparisons fail)
- Assuming numeric input only (mixed types crash)

Real-world examples:

Stock price trends: non-decreasing prices over time?
Machine learning: validation / training loss monotonically decreasing?
Timestamp / event log validation: events in non-decreasing order?
Sensor data checks: readings steadily increasing or decreasing?

For the full deep dive (including configurable strict mode and more code), check the original on emiTechLogic: https://emitechlogic.com/monotonic-sequence-in-python/

What's your favorite method?

Ever hit a monotonic bug in production?

Drop a comment below — I'd love to hear!

Want to Read More?

If you enjoyed this deep dive into checking monotonic sequences in Python, here are some related articles from emiTechLogic that build on similar concepts:

Check if a List is Sorted in Python — Learn multiple ways to verify if a list is already sorted (closely related to monotonic checks, since a sorted list is monotonic by definition).
Check if a Tuple is Sorted in Python — Extend the idea to immutable sequences like tuples.
Sorting Algorithms in Python — Understand why we avoid sorted() for monotonic checks and explore actual sorting implementations.
Python Tuples — Dive deeper into tuples, which often appear in pairwise/monotonic-related problems.
Top 10 Python Interview Questions — More common interview problems like this one (including sequence and data structure questions).
Python Optimization Guide: How to Write Faster, Smarter Code — Tips on performance that complement our discussion of O(n) vs O(n log n) approaches.

For the full collection of Python tutorials, guides, and interview prep, visit the emiTechLogic Blog.

5 Efficient Ways to Check if a Python Tuple is Sorted (Without Sorting It!)

Emmimal P Alexander — Thu, 19 Feb 2026 03:05:52 +0000

If you've ever needed to validate if a tuple in Python is sorted—maybe for data integrity or interview prep—this guide has you covered. Tuples are immutable, so no in-place sorting like lists. Instead, we'll focus on efficient pairwise checks that run in O(n) time with early exits.
We'll cover 5 methods, from one-liners to loop-based approaches, plus tips for descending order, keys, and edge cases.

Why Check Tuples Differently?

Tuples can't be sorted in place (t.sort() raises AttributeError). sorted(t) returns a list, which is wasteful for just a boolean. Our methods avoid sorting entirely.

Method 1: all() with zip() (Recommended)

def is_sorted(t):
    return all(x <= y for x, y in zip(t, t[1:]))

Non-decreasing (duplicates OK).
For strict: Use <.
Handles empty/single-element: True.

How it works: Pairs elements (e.g., (1,2), (2,3)) and checks lazily.

Method 2: For Loop (Interview Favorite)

def is_sorted(t):
    for i in range(len(t) - 1):
        if t[i] > t[i + 1]:
            return False
    return True

Clear and extensible (e.g., return violation index).

Method 3: all() with range()

def is_sorted(t):
    return all(t[i] <= t[i + 1] for i in range(len(t) - 1))

Index-based one-liner.

Method 4: itertools.pairwise() (Python 3.10+)

from itertools import pairwise

def is_sorted(t):
    return all(x <= y for x, y in pairwise(t))

Memory-efficient—no slicing.

Method 5: sorted() Comparison (Simple but Slow)

def is_sorted(t):
    return t == tuple(sorted(t))

O(n log n)—use for small tuples only.

Descending and Key-Based Checks

For descending: Flip to >= or >.
For keys (e.g., sort by salary in records):

import operator
def is_sorted_by(t, key=operator.itemgetter(2)):
    return all(key(x) <= key(y) for x, y in zip(t, t[1:]))

Edge Cases Quick Hits

Empty/single: True.
Duplicates: OK with <=.
Mixed types: Wrap in try-except.
Nested tuples: Lexicographic by default.
None: Custom compare function.

Performance

All but Method 5 are O(n) with early exit. See the full article for a timeit benchmark script!
These work on lists too—tuples/lists are sequences at heart.
What’s your go-to method? Share in the comments! For more details, including FAQs and resources, head to the original post on EmiTechLogic.

Want to dive deeper into Python sequences, performance, or related concepts? Here are some hand-picked reads from EmiTechLogic:

Python Tuples – Everything You Need to Know — Deep dive into tuples (immutability, methods, use cases).
Check if List is Sorted in Python — Similar techniques adapted for mutable lists.
Python Optimization Guide: How to Write Faster, Smarter Code — More on avoiding unnecessary sorts and O(n) patterns.
Python Lists — Complements the tuple discussion with mutable sequences.
Mutable vs Immutable in Python — Explains why tuples behave differently from lists.
Python Slicing and Indexing – The Complete Beginner's Guide — Key to understanding t[1:] in Method 1 .

Stop Sorting Just to Check Order: 5 Fast O(n) Methods in Python

Emmimal P Alexander — Tue, 17 Feb 2026 05:41:46 +0000

The Problem With Using sort() Just to Verify Order

A common mistake I see (and have made!):

Don't do this for validation

def is_sorted_bad(lst):
    return lst == sorted(lst)

Python's Timsort is O(n log n) and copies the whole list. For a million elements? ~20 million operations and extra memory — just for a yes/no! 😩
When the list is already sorted (often the case), it's pure waste.
Big O graph showing O(n log n) vs O(n)
Caption: Why sorting for verification hurts performance
The methods below are all O(n) with early exit — they stop at the first out-of-order pair.

Quick Note: What Does "Sorted" Mean?

Non-decreasing: Allows duplicates (<=) → [1, 2, 2, 3] ✅
Strictly increasing: No duplicates (<) → [1, 2, 2, 3] ❌

Same for descending (flip operators). All methods assume comparable elements.

Method 1: all() + zip() — The Go-To Pythonic Way 🔥

def is_sorted(lst):
    return all(x <= y for x, y in zip(lst, lst[1:]))

# Strictly increasing
def is_strictly_sorted(lst):
    return all(x < y for x, y in zip(lst, lst[1:]))

Lazy evaluation + early exit = super efficient.

Method 2: Classic For Loop — Interview Favorite

def is_sorted(lst):
    for i in range(len(lst) - 1):
        if lst[i] > lst[i + 1]:
            return False
    return True

Method 3: all() + range() — When You Need the Index

def is_sorted(lst):
    return all(lst[i] <= lst[i + 1] for i in range(len(lst) - 1))

Great for extensions like finding the first violation.

Method 4: itertools.pairwise() — Cleanest (Python 3.10+)

from itertools import pairwise

def is_sorted(lst):
    return all(x <= y for x, y in pairwise(lst))

No slice overhead — true O(1) space!

Method 5: operator.le — For Custom Objects

import operator

def is_sorted_by(lst, key):
    return all(key(x) <= key(y) for x, y in zip(lst, lst[1:]))

Perfect for sorting objects by attribute.

Descending Order? Just Flip It!

Ascending vs Descending

def is_non_increasing(lst):
    return all(x >= y for x, y in zip(lst, lst[1:]))

Edge Cases

Empty/single-element lists → Always True
Mixed types → TypeError (wrap in try/except)
None values → Handle manually

Performance Quick Comparison

Method	Time/Space Notes	Best For
all() + zip()	Readable, common	Everyday use
For loop	Clear, no tricks	Interviews
all() + range()	Useful when index is needed	Extensions (e.g., finding first violation)
pairwise()	True O(1) space	Modern Python (3.10+)
operator.le	Great for custom objects	Key-based or attribute sorting

NumPy/Pandas? Use Their Built-ins!

# NumPy
np.all(arr[:-1] <= arr[1:])

# Pandas
series.is_monotonic_increasing

When sort() Wins

If you need the sorted list anyway → Just call .sort() — Timsort is O(n) on sorted data!

That's it! Which method do you use most? Drop a comment below 👇
For the complete guide (with FAQs, full quiz, and more edge cases), head to my blog:
https://emitechlogic.com/check-if-list-is-sorted-python/

How Python Searches Data: Linear Search, Binary Search, and Hash Lookup

Emmimal P Alexander — Wed, 11 Feb 2026 03:50:22 +0000

Let me show you something you probably write every day:

if user_id in active_users:
    grant_access()

That tiny word in looks simple—just checking if something exists in a collection. You write it without thinking.

But here’s the secret: Python searches through your data in completely different ways depending on the collection type (list, set, or dictionary).

Think of looking for a book like this:

Check every book on the shelf one by one → linear search
Jump to the middle and eliminate half the books (if sorted) → binary search
Use a catalog that points exactly where the book is → hash lookup Python does the same. The search method depends on your collection choice. Let’s explore each, when to use them, and why it matters.

Why Understanding Search Methods Matters

Python doesn’t pick the fastest way automatically—it bases everything on the collection type:

List → one way
Set → another
Dictionary → yet another

Examples:

# List: sequential check
users_list = ["alice", "bob", "charlie"]
if "alice" in users_list:  # Checks one by one
    print("Found!")

# Set: direct jump
users_set = {"alice", "bob", "charlie"}
if "alice" in users_set:  # Instant!
    print("Found!")

With 1,000,000 items:

List → up to 1,000,000 checks
Set → ~1 step

That’s the difference between instant and seconds.

Linear Search in Python Lists

Linear search checks items sequentially, like finding a friend in a line.

def linear_search_explained(items, target):
    print(f"Looking for: {target}")
    for index, item in enumerate(items):
        print(f"Step {index + 1}: Checking {item}")
        if item == target:
            print(f"Found at position {index}!")
            return True
    print("Not found")
    return False

linear_search_explained([5, 12, 8, 30, 15], 30)

Best case: 1 check (first item)

Worst case: all items

Python’s built-in in is fast (C-implemented), but it’s still O(n).

Use linear search for:

Small data (<100 items)
Unsorted or frequently changing data
Items usually near the start

Avoid it for large, frequent searches.

Binary Search: For Sorted Data

Binary search halves the search space at each step—like guessing a number.

import bisect

# Must be sorted!
sorted_users = [101, 205, 347, 892]

index = bisect.bisect_left(sorted_users, 205)
if index < len(sorted_users) and sorted_users[index] == 205:
    print("Found!")

Max checks: ~log₂(N)

(~20 steps for 1,000,000 items)

Use when:

Data is sorted
Multiple searches are required

Don’t sort just for one search—the cost may exceed the benefit.

Sort once for many searches, or use sets for constant-time lookups.

Hash Lookup: Instant Access

Sets and dictionaries use hash tables for near-constant time lookups.

blocked_emails = {"spam1@bad.com", "spam2@bad.com"}

if email in blocked_emails:  # O(1) average
    print("Blocked")

Direct jump via hash function
Rare collisions handled gracefully

Higher memory use, but unbeatable for frequent membership tests and key lookups.

Performance Comparison

Quick Decision Guide

Scenario	Best Choice	Why
Frequent membership checks	Set	O(1) hash lookup
Key-value pairs	Dict	O(1) access
Sorted data, many searches	List + bisect	O(log N)
Small, unsorted, one-time search	List	Simple, low overhead

Common Mistakes

Binary search on unsorted data → wrong results silently
Converting to set inside loops → repeated cost
Using lists for “seen before” tracking → use sets
Sorting for single searches → wasteful

Final Advice

Choose the right data structure upfront—that determines search speed.

Need fast in checks? → Set
Key-value access? → Dict
Order matters? → List
Sorted + fast search? → List + bisect

Your programs will thank you!

This article was originally published on my blog: How Python Searches Data. Check it out there for any updates or more content!

I Implemented Every Sorting Algorithm in Python — And Python's Built-in Sort Crushed Them All

Emmimal P Alexander — Thu, 05 Feb 2026 06:13:15 +0000

Last month, I went down a rabbit hole: I implemented six classic sorting algorithms from scratch in pure Python (Bubble, Selection, Insertion, Merge, Quick, Heap) and benchmarked them properly on CPython.

I expected the usual Big-O story. What I got was a reality check: Python's interpreter overhead changes everything.

Textbooks say Quick/Merge/Heap are fast. In Python? They're okay... but sorted() (Timsort) beats them by 5–150×. Here's why — and when you should never write your own sort.

The Surprise Results (Real Benchmarks)

I tested on random, nearly-sorted, reversed, and duplicate-heavy data using timeit with warm-ups, median timing, and GC controls.

Algorithm	100 elements	1,000 elements	5,000 elements	Practical Limit
Bubble Sort	0.001s	0.15s	3.2s	~500 elements
Selection Sort	0.001s	0.13s	2.8s	~500 elements
Insertion Sort	0.0005s	0.08s	1.9s	~1,000 (great on nearly-sorted!)
Merge Sort	0.002s	0.025s	0.14s	Usable but slow
Quick Sort	0.002s	0.021s	0.11s	Usable but recursion hurts
Heap Sort	0.002s	0.029s	0.16s	Reliable but never wins
sorted()	0.0003s	0.0045s	0.025s	Use this always

Key shocks:

Insertion sort beats Merge/Quick on <100 elements (low overhead wins).
Bubble sort dies at ~1,000 elements due to expensive comparisons.
Timsort (built-in) exploits real-world patterns and runs in C — untouchable.

Why Hand-Written Sorts Lose in Python

Comparisons are expensive: a > b → method dispatch, type checks (not one CPU instruction).
Recursion overhead: Quick sort's function calls are costly.
Memory allocations: Merge sort creates thousands of temporary lists → GC pauses.
Timsort is a hybrid genius: Detects runs, uses insertion sort for small chunks, merges adaptively — all in optimized C.

Example: Insertion sort (often the small-data winner):

def insertion_sort(arr):
    arr = arr.copy()
    for i in range(1, len(arr)):
        key = arr[i]
        j = i - 1
        while j >= 0 and arr[j] > key:
            arr[j + 1] = arr[j]
            j -= 1
        arr[j + 1] = key
    return arr

The Verdict

Never implement your own sort in production Python.

Use sorted() or .sort() — they’re faster, stable, and battle-tested.

Do it only for learning purposes or rare edge cases.

Want the full deep dive?

Detailed explanations
All source code
Benchmark script
Raw benchmark data

👉 Read the complete post on my blog:

https://emitechlogic.com/sorting-algorithm-in-python/

Run the benchmarks yourself

GitHub Repository: https://github.com/Emmimal/python-sorting-benchmarks

What surprised you most about Python’s sorting performance?

Drop a comment — curious to hear your take.

Python Tuples: Not Just Immutable Lists – They're Design Contracts

Emmimal P Alexander — Tue, 03 Feb 2026 04:58:03 +0000

Tuples in Python are often dismissed as "immutable lists." But that's selling them short. In reality, a tuple is a design contract — a deliberate promise to anyone reading (or maintaining) your code that this collection will never change its structure.

Choosing a tuple over a list isn't just about performance or hashability. It's about intent. It's about making your code more readable, more predictable, and less prone to subtle bugs.

In this post, we'll explore why tuples exist, when they shine, and how to use them intentionally. (This article is based on a deeper guide I wrote on my blog — full version here with interactive examples and more advanced patterns.)

Why Tuples Aren't Just "Read-Only Lists"

Yes, tuples are immutable in structure:

You can't append, remove, or reorder elements.
They use less memory than lists.
They are hashable (when containing only immutable items), so they can be dictionary keys or set members.

But the real power comes from what immutability communicates:

# List — says "this might grow or change"
coordinates = [10.5, 20.3]

# Tuple — says "these values are fixed together"
coordinates = (10.5, 20.3)

Anyone reading the second line immediately knows: these two values belong together and won't be tampered with accidentally.

The Immutable Container Trap (and How to Avoid It)

A common gotcha: tuples are structurally immutable, but their contents can still be mutable.

data = (42, ["apple", "banana"])

data[1].append("cherry")  # This works!
print(data)  # (42, ['apple', 'banana', 'cherry'])

The tuple's shape didn't change — but the data inside did. This breaks the "design contract" if you expected complete stability.
Golden rule: If you want true immutability, only store immutable objects inside tuples (numbers, strings, other immutable tuples).

When to Reach for a Tuple: A Quick Decision Checklist

| Scenario                                   | Prefer Tuple? | Why                                      |
|--------------------------------------------|---------------|------------------------------------------|
| Returning multiple values from a function  | Yes           | Fixed order, no accidental mutation       |
| Coordinates, RGB colors, simple records    | Yes           | Meaning is obvious from position          |
| Configuration values that never change     | Yes           | Signals intent clearly                    |
| Data that will grow or be modified often   | No            | Use a list instead                       |
| 4+ fields or shared/public code             | Consider `namedtuple` | Better readability and self-documentation |

Named Tuples: Tuples That Read Like Classes

When positional access becomes unclear:

# Hard to read
user = ("alice", "active", 28, "engineer")

# Much clearer
from collections import namedtuple

User = namedtuple("User", ["name", "status", "age", "role"])
user = User("alice", "active", 28, "engineer")

print(user.status)  # Clean and self-documenting

Named tuples give you dot-access readability while keeping the lightweight, immutable benefits of regular tuples.

Real-World Wins with Tuples

Dictionary keys for caching:

@lru_cache(maxsize=128)
def expensive_calc(user_id, region):
    # (user_id, region) tuple is hashable → perfect cache key

Multiple return values:

def divide(dividend, divisor):
    quotient = dividend // divisor
    remainder = dividend % divisor
    return quotient, remainder  # Packed safely into a tuple

Constants and configuration:Python

DATABASE_CONFIG = ("localhost", 5432, "mydb", "user", "pass")

Final Thoughts

Next time you're about to write a list, pause and ask: "Does this data really need to change?" If the answer is no, reach for a tuple. You're not just saving a few bytes — you're making your code's intent crystal clear.
Want more examples, interactive demos, and a deeper dive into tuple performance and advanced patterns? Check out the full article on my blog:
🔗 Python Tuples: Immutability as a Design Contract (https://emitechlogic.com/python-tuples/)
Let me know in the comments: Do you treat tuples as a deliberate design choice, or just as immutable lists? I'd love to hear your experiences!

Why Reversing a String in Python Isn't as Simple as You Think (And What It Reveals About AI Limits)

Emmimal P Alexander — Sat, 31 Jan 2026 06:11:27 +0000

Reversing a string is one of the first things you learn in Python.

It feels trivial.

"Python"[::-1]
# nohtyP

Done. Move on.

But that tiny operation hides important lessons about memory, performance, and why AI systems struggle with tasks that look “easy” to humans.

This post uses string reversal to explore three deeper ideas:

How Python actually handles strings in memory

Why some reversal methods quietly waste RAM

Why large language models fail at character-level tasks — and what that means for real AI systems

If you’ve ever worked with large files, production systems, or AI-powered pipelines, this matters more than you think.

When Does String Reversal Actually Matter?

If you’re reversing a few words, anything works.

But things change when:

You’re processing hundreds of MBs of logs
You’re running inside Docker with strict memory limits
You’re handling DNA sequences or scientific data
Your system runs every minute, not once Pick the wrong method and your program doesn’t slow down — it dies.

Python String Reversal with Slicing [::-1]

This is the method everyone knows:

original = "Python"
reversed_str = original[::-1]

What [::-1] Really Means

The slicing format is:

[start : stop : step]

Leaving start and stop empty means “use the entire string”.
A step of -1 means “walk backwards”.

But here’s the key detail most people miss:

Python creates a brand-new string in memory.

It doesn’t swap characters in place.
Strings are immutable, so slicing copies everything.

Why This Is So Fast

Slicing happens inside CPython’s C implementation (unicodeobject.c).

That gives Python three advantages:

Memory is allocated once
Data is copied using optimized C routines
No Python-level loop runs per character

For normal-sized strings, this is the fastest approach.

The Hidden Cost: Memory Duplication

Let’s visualize what happens:

Original string (memory):

P y t h o n

After slicing [::-1]:

n o h t y P

You now have two full strings in memory.

For a 500 MB file:

Original: 500 MB
Reversed copy: 500 MB
Peak usage: 1 GB

That’s how scripts crash in production.

Memory-Efficient Reversal with reversed()

Now look at this:

text = "Large dataset"
reversed_text = "".join(reversed(text))

Why This Uses Less Memory

reversed() does not copy the string.

It returns an iterator — a tiny object that remembers:

Where the string lives in memory
Which index comes next

This is lazy evaluation. Nothing is copied until join() runs.

Why join() Is Required

An iterator isn’t a string.

join():

Calculates final size
Allocates memory once
Writes characters efficiently

This avoids the catastrophic behavior of string concatenation in loops.

Real-World Scenario Where This Matters

Imagine a log-processing service:

Each log file: ~200 MB
Thousands of files per day
Running inside a container

Using slicing everywhere means memory spikes that kill the process.

Iterators give Python breathing room — especially when garbage collection can reclaim unused objects earlier.

Performance Comparison (Reality, Not Theory)

| Method                  | Time            | Memory          | When to Use             |
| ----------------------- | --------------- | --------------- | ----------------------- |
| `[::-1]`                | Fastest         | Full copy       | Small–medium strings    |
| `reversed()` + `join()` | Slightly slower | Memory-friendly | Large files             |
| Manual loop             | Very slow       | Inefficient     | Never                   |
| List comprehension      | Medium          | Full copy       | When transforming chars |

For most applications:
Slicing wins on speed. Iterators win on safety.

If you want a deeper breakdown with examples, I’ve written a full guide here:
👉 https://emitechlogic.com/how-to-reverse-a-string-in-python/

Why AI Models Fail at String Reversal

Here’s the fun part.

AI systems like ChatGPT can explain string reversal perfectly —
yet often fail to reverse “strawberry” correctly.

They also struggle to count letters accurately.

This Isn’t a Bug

Language models don’t see characters.

They see tokens.

“Python” might become:

["Py", "thon"]

The model processes token IDs, not letters.

To reverse a word, it would need to:

Reconstruct characters from tokens
Reverse them precisely
Emit new tokens matching the reversed text

That’s not what it was designed to do.

Pattern Recognition vs Symbolic Logic

Language models excel at:

Text generation
Context understanding
Pattern completion

They fail at:

Exact counting
Character-level manipulation
Step-by-step algorithms That’s why AI can write code that reverses strings, but can’t reliably reverse strings itself.

The logic lives in Python — not the model.

Where This Becomes Critical: Bioinformatics

In genomics, reversing strings is not optional.

DNA analysis requires reverse complements:

def reverse_complement(seq):
    table = str.maketrans("ATCG", "TAGC")
    return seq[::-1].translate(table)

One wrong character means:

Wrong gene
Wrong protein
Wrong conclusion

This is why scientists use code for precision
and AI for interpretation, never the other way around.

How Production AI Systems Should Be Built

The lesson is simple:

AI suggests. Code decides.

Use Python for:

Validation
String manipulation
Math
Security
Exact logic
Use AI for:
Understanding intent
Summarization
Pattern discovery
Natural language output

This separation is not a weakness — it’s good architecture.

Final Takeaway

Reversing a string isn’t hard.

Understanding how and why it works reveals:

How Python manages memory
Why performance trade-offs matter
Where AI systems hit real limits

Tiny operations expose big truths.

And once you see them, you start building faster, safer, and smarter systems.

TL;DR

[::-1] is fast but duplicates memory

reversed() is safer for large data

AI models don’t operate at character level

Production systems need code + AI, not AI alone

If you enjoyed this breakdown, the hands-on Python examples live here:
👉 https://emitechlogic.com/how-to-reverse-a-string-in-python/

For more visits: https://emitechlogic.com/blog/