Groupby Latest Status Verdict

Decides whether a "current row per id" call actually returns the latest row. Pure function over facts about your call and your data: no pandas, no dataframe, no I/O.

Measured against pandas 3.0.5. NOT a pandas bug report.

CASE 1 — ONE LATE-ARRIVING ROW SILENTLY REGRESSES THE REPORTED STATUS:

    before: {'C1': 'delivered', 'C2': 'shipped'}

    append ONE C1 row, status='payment_verified', timestamped BEFORE 'shipped'
    -- genuinely older -- via pd.concat(ignore_index=True). No re-sort.

    after : {'C1': 'payment_verified', 'C2': 'shipped'}      <- identical call

THE STATUS WENT BACKWARDS. No code change, no error, no warning, no diff to point at. .last() returns whichever row is physically last in the frame's current order, not the row with the maximum timestamp. groupby(sort=False) does not help -- that parameter orders the group KEYS, not the rows inside a group. drop_duplicates(keep='last') has the identical defect.

A late-arriving row is not an edge case: delayed webhook replays, cross-region syncs and backfill corrections all produce one.

CASE 2 — SORTING FIRST IS THE STANDARD FIX, AND IT DOES NOT RESOLVE A TIE. 40 rows tied at the maximum timestamp, one group:

    sort_values(kind="quicksort")  -> tied_39     <- pandas' DEFAULT
    sort_values(kind="mergesort")  -> tied_39
    sort_values(kind="stable")     -> tied_39
    sort_values(kind="heapsort")   -> tied_0
    idxmax                         -> tied_0

    18 DISTINCT ANSWERS across 12 input shuffles x 4 sort kinds -- same question, same data.

Sorting moves the arbitrariness from "row order" to "row order among the tied rows". And the two recommended fixes pick OPPOSITE ENDS of a tie: sort_values then .last() takes the last of the tied rows, idxmax returns the FIRST occurrence of the maximum. Two people fixing the same bug in the two blessed ways get two different answers, and neither is warned. heapsort differs because it is not stable; pandas' default quicksort is also not stable and merely happens to agree here, which is worse than disagreeing.

THE ONLY REAL REMEDY IS IN THE DATA, NOT THE CALL: sort by (time, a monotonic tiebreaker) so the ordering is total. This package says that rather than recommending a different arbitrary answer.

CASE 3 — .last() SKIPS NULLS, SO IT IS NOT THE LAST ROW'S VALUE EITHER. On a frame whose physically-last row has status=None:

    groupby.last()              {'C1': 'shipped'}    <- the value from the row BEFORE it
    groupby.last(skipna=False)  {'C1': nan}
    groupby.nth(-1)             [nan]
    drop_duplicates(keep=last)  [nan]
    idxmax path                 [nan]

Every other call shape returns NaN. .last() alone walks backwards to the previous non-null, so A CLEARED STATUS READS AS THE PREVIOUS STATUS. Whether that is what you want is a real question -- if a null means "no change", skipping is correct. It should be a decision, not a default nobody read.

CASE 4 — ONE PATH IS LOUD, STATED IN ITS FAVOUR. With every time value NaT in a group, idxmax RAISES ValueError while sort_values then .last() silently returns a row. That is the only loud failure anywhere in this measurement and a real reason to choose idxmax on purpose. A listing that only reports what a library gets wrong is not being honest about it.

IT FAILS CLOSED. Every fact accepts "unknown", and "unknown" is never read as false. sortKind is REQUIRED for the sort_values shape rather than defaulting to "quicksort": defaulting would answer about pandas' default when the caller may have passed something else, and the kind changes the row returned. A certain defect is never softened by an unrelated unknown -- WRONG_ROW outranks UNDECIDABLE.

A FRAME THAT IS SORTED AT THE CALL RETURNS AMBIGUOUS, NOT CORRECT. The answer agrees today, but the correctness now lives in whatever sorted the frame -- usually elsewhere in the pipeline, and never named at the line you are reading.

THE HONEST CAVEAT, CARRIED RATHER THAN SMOOTHED OVER: a sentence describing row order within a group does exist in pandas' docs -- in groupby()'s own sort parameter docstring, which nominally documents group-KEY ordering, not row selection inside .last(). Case 1 alone would be thin ground for a product. Cases 2, 3 and 4 are where this earns its place.

VERIFIED: 24 tests, measured by running the suite, every mutation observed FAILING before restore.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function evaluateLatestSelection(input: GroupLatestInput): GroupLatestVerdict;

  export type SortKind = "quicksort" | "mergesort" | "stable" | "heapsort" | "unknown";
  export type Severity = "critical" | "warning" | "note";