enumerate() and zip() in Python

enumerate wraps an iterable and gives you index-and-value pairs, while zip places the items of several iterables next to each other.

fruits = ['apple', 'banana', 'cherry']

for index, fruit in enumerate(fruits):
    print(index, fruit)

# The start argument changes where the numbering begins.
print(list(enumerate(fruits, start=1)))

numbers = [10, 20, 30]
letters = ['x', 'y']
print(list(zip(numbers, letters)))

The first loop prints 0 apple, 1 banana, and 2 cherry. The enumerate call with start=1 gives the pairs (1, 'apple'), (2, 'banana'), and (3, 'cherry'). The zip of a three-item list with a two-item list gives only two pairs, which are (10, 'x') and (20, 'y'). The value 30 has no partner, so it is dropped without any warning.

That truncation is the single most important fact about zip. It stops as soon as the shortest iterable is finished, and it does not tell you that it has done so. It is exactly what you want when you are pairing two files that are guaranteed to line up, and it is a silent data-loss bug when they are not.

Two details about enumerate are worth knowing. The start argument takes any number, so enumerate(items, start=1) gives one-based numbering, which is often what you want for output that people read. And enumerate does not need the iterable to support indexing, so it works with generators, which is a real advantage over the older habit of writing range(len(items)).

Finally, zip is lazy, which means it produces pairs as it goes, so you should wrap it in list() when you want a concrete list that you can index into or reuse.

Tracking a counter by hand means writing counter = 0 before the loop and counter += 1 inside the body. That is two extra lines and one more thing to forget. The failure mode is quiet as well, because if the body of the loop contains a continue, the increment can be skipped and the numbering goes wrong. enumerate removes that whole class of problem, because it produces the index for you.

items = ['a', 'b', 'c']

# The version that can go wrong.
counter = 0
for item in items:
    if item == 'b':
        continue
    print(counter, item)
    counter += 1

# The version that cannot go wrong.
for index, item in enumerate(items):
    if item == 'b':
        continue
    print(index, item)

enumerate is also tidier, because it does not do a separate length lookup and index operation on the sequence for every single round, and it works with any iterable at all, including generators, where range(len(...)) is impossible because a generator has no length.

Now the zip side of the question. Truncation hides a difference in length. Two files, two lists, or two API responses are supposed to correspond one to one, so if one of them is short then zip quietly produces fewer pairs, and every count you make afterwards is wrong. Nothing is raised, nothing is logged, and the loss of data only shows up later as a puzzling discrepancy.

So the defensive habits are these. Check len(a) == len(b) when the one-to-one correspondence is a requirement. Use itertools.zip_longest with an explicit fill value when it is not. And use dict.items() instead of zipping keys and values when the two sides come from a single dictionary. The general principle is that any tool which truncates without a warning should be paired with a deliberate length check.