Skip to content

fix: sort example had identical buggy and fixed functions - #204

Open
nareshAiNexus wants to merge 1 commit into
multica-ai:mainfrom
nareshAiNexus:fix/sort-example-buggy-fn
Open

nareshAiNexus wants to merge 1 commit into
multica-ai:mainfrom
nareshAiNexus:fix/sort-example-buggy-fn

Conversation

@nareshAiNexus

Copy link
Copy Markdown

What is broken

In Example 3 of the Goal-Driven Execution section, the buggy version and the fixed version of sort_scores are exactly the same:

Before (labeled buggy)
\\python
def sort_scores(scores):
return sorted(scores, key=lambda x: (-x['score'], x['name']))
\\

After (labeled fix)
\\python
def sort_scores(scores):
return sorted(scores, key=lambda x: (-x['score'], x['name']))
\\

The whole point of the example is to show the test failing first, then passing after the fix. That never happens here because both functions produce the same output.

The comment also says 'run 10 times, fails with inconsistent ordering'. That is not accurate. Python's sorted() is stable, nothing is random. The real problem is the order is input-dependent for ties, not that it is random.

What this PR fixes

Changed the buggy version to sort by score only, no tie-break:

\\python
def sort_scores(scores):
return sorted(scores, key=lambda x: -x['score'])
\\

Now the two versions are different. The test fails on the buggy version because Alice and Bob come out in input order instead of alphabetical. After the fix adds the name key, the test passes.

Also updated the verify comment to say what actually happens instead of claiming random failures.

Changes

  • \EXAMPLES.md\ — 2 lines changed, nothing else

The 'bad' implementation used the same key as the fix:
(-x['score'], x['name']). That means the test would pass
before the fix was applied, defeating the whole point.

Changed the buggy version to -x['score'] only (no tie-break),
so duplicates keep input order instead of sorting alphabetically.
That's the actual bug the example is trying to demonstrate.

Also dropped the 'run 10 times' claim — Python's sorted() is
stable so nothing is random. The real issue is order correctness,
not non-determinism.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant