Introduction

Checking whether an element exists in exactly one of two arrays is a small problem, but the best solution depends on what you mean by "exists." If you only care about membership, a set-based answer is usually best. If duplicates matter, you need a counting approach instead of simple membership.

Solve the Simple Membership Case With an XOR Check

If the question is about one specific value, the cleanest test is to compare the membership result from both arrays and ask whether they differ.

1def exists_in_exactly_one(value, left, right):
2    return (value in left) != (value in right)
3
4print(exists_in_exactly_one(3, [1, 2, 3], [4, 5]))      # True
5print(exists_in_exactly_one(3, [1, 2, 3], [3, 4, 5]))   # False

This works because the expression is true only when one side contains the value and the other side does not. It is readable and correct for ad hoc checks on small arrays.

Use Sets When You Need Many Membership Checks

If you need to test many values, converting arrays to sets once is faster than repeated linear scans. Sets also make it easy to compute the symmetric difference, which is the set of elements that appear in one side only.

1left = [1, 2, 3, 3, 6]
2right = [3, 4, 5, 6]
3
4exclusive = set(left) ^ set(right)
5print(exclusive)   # {1, 2, 4, 5}

This is often the best answer when order does not matter and duplicate counts do not matter. It is also a direct expression of the actual concept, which makes the code easier to read than nested loops.

Keep Duplicates Only If the Problem Requires Them

Set logic collapses duplicates. That is correct for many problems, but not all of them. If you need to know which occurrences remain exclusive after cancellation, use Counter.

1from collections import Counter
2
3left = [1, 2, 2, 3]
4right = [2, 3, 3, 4]
5
6exclusive_counts = (Counter(left) - Counter(right)) + (Counter(right) - Counter(left))
7exclusive_items = list(exclusive_counts.elements())
8
9print(exclusive_items)   # [1, 2, 3, 4]

In this example, one 2 remains exclusive to the left side and one 3 remains exclusive to the right side after shared occurrences are removed.

Avoid Nested Loops Unless the Arrays Are Tiny

A straightforward loop can work, but it scales poorly because each membership test scans the other array again. For a single comparison on tiny inputs, this does not matter. For repeated operations or larger arrays, it becomes unnecessary overhead.

1def slow_check(value, left, right):
2    in_left = False
3    for item in left:
4        if item == value:
5            in_left = True
6            break
7
8    in_right = False
9    for item in right:
10        if item == value:
11            in_right = True
12            break
13
14    return in_left != in_right

This version is not wrong, but it communicates less clearly than value in left and value in right. Most of the time, the better solution is the simpler one.

Pick the Data Model Before the Algorithm

The real design question is whether your arrays represent sets, ordered lists, or multisets. Once that is clear, the implementation choice becomes obvious:

• One value, one check: compare two membership tests.
• Many values, duplicate-insensitive: use sets and symmetric difference.
• Duplicate-sensitive: use Counter.

The mistake is not usually the syntax. It is choosing a solution that answers a different question from the one your data actually asks.

Common Pitfalls

• Using a set-based solution when duplicate counts are semantically important.
• Writing nested loops for repeated checks when a one-time set conversion would be much faster.
• Confusing "only in left" with "only in one of the arrays," which are different operations.
• Forgetting that sets discard order, which matters if you need to preserve the original sequence.
• Comparing custom objects without defining equality and hashing behavior appropriately for set use.

Summary

• For one value, compare membership on both sides and keep the XOR logic explicit.
• For many checks, convert to sets and use symmetric difference.
• If duplicates matter, switch to Counter instead of set.
• Match the algorithm to the data model, not just to the word "array."
• Prefer the clearest expression of the rule over manual looping.