Lists: Intermediate

A slice pulls a run of consecutive items out of a list and returns them as a new list. You already know the syntax from strings: daily_rows[start:stop] takes the items from position start up to, but not including, position stop. What comes back is always a list, even when the run holds a single item or none at all.

Compare the last 2 lines. daily_rows[3:4] is a 1-item list, [160], while daily_rows[3] is the number 160 itself. Code that expects a number and receives a list fails at the next arithmetic step, so pick the form you need. When start and stop both fall inside the list, the slice holds stop - start items: [2:5] always returns 3. When start sits at or after stop, the count bottoms out at 0 and the slice is empty: daily_rows[5:2] returns []. Python raises no error and doesn't walk backwards.

Leaving out start means from the first item, and leaving out stop means through the last. Negative positions count from the end, as they do for strings, so [-3:] reads as the last 3 items however long the list grows. That matters in a daily job: a report on the most recent 3 days shouldn't hard-code [5:], because tomorrow the list holds 9 items and [5:] returns 4 of them.

The third number is the step. Python takes the item at start and jumps ahead by the step to take the next one, repeating until it reaches stop. With a step of 2, [::2] returns every odd day from 1 to 7. [1::2] returns every even day from 2 to 8. A pipeline uses this to split records into 2 alternating halves, or to sample every 3rd record for a spot check.

Indexing a position past the end raises IndexError. Slicing past the end does not: Python clips start and stop to the edges of the list and returns whatever falls between them, possibly an empty list. daily_rows[5:20] returns the 3 items from position 5 through 7. daily_rows[20:30] returns []. That helps when you want up to N items from a list that might be shorter, and hurts when a short result should have stopped the job, because nothing warns you.

Appending to recent leaves daily_rows with its original 8 items, because the slice built a new list holding the same values. daily_rows[:], a slice with both ends left out, is the shortest way to get a full separate list that you can change without touching the original.

To predict a slice with a step, write out the positions it visits before reading any values. For daily_rows[2:7:2], start at position 2 and add 2 each time. That visits every even position up to 6. The next would be 8, which is past the stop of 7, so the walk ends. Only then look up the values: [98, 142, 171]. Listing positions first catches 2 frequent mistakes: counting the stop position as included, and forgetting that the step jumps over the items in between.

+ copies the items of the left list, then the items of the right list, into a brand-new list. Neither input changes, and order follows the operands: tuesday + monday puts Tuesday first. Both sides must be lists. monday + "r104" raises TypeError: can only concatenate list (not "str") to list, so wrap a single item in brackets: monday + ["r104"].

team_a.extend(team_b) adds each item of team_b to the end of team_a. Afterwards team_a holds 5 names and team_b still holds its 2, and no third list exists. For lists, team_a += team_b behaves like extend(): it adds to the existing list rather than building a new one.

append() adds its argument as a single item, whatever that argument is. Given a list, it adds the whole list as one element, so batch ends with a nested list and has a length of 3. A loop over that batch would hand its third pass a list where it expects an ID. extend() walks through its argument and adds each item separately, giving the 4 IDs you meant.

Multiplying a list by an integer n builds a new list holding its items n times over. [0] * 7 is a common way to start 7 daily counters before a loop fills them in. Numbers and strings repeat this way, and so does None. An empty list repeated any number of times stays empty.

Starting from an empty list and extending once per batch is the standard pattern for gathering many lists into one. The empty batch adds nothing and raises no error. Writing all_ids = all_ids + batch gives the same result, but builds a fresh list on every pass and copies everything gathered so far, which slows down as the total grows.

When several names are in play, track each one line by line. with_header() combines with +, so it hands back a separate list and leaves its argument with the 2 IDs it started with. Extending data afterwards changes data alone: out still prints 3 items. A function that builds its result with + is the safer choice whenever the caller still needs its input as it was.

Two lists are equal when they have the same length and every pair of items in matching positions is equal. Python starts at position 0 of both lists and moves forward one position at a time until it finds a pair that differs. Order counts: [1, 2, 3] == [3, 2, 1] is False because position 0 holds 1 on the left and 3 on the right.

A pipeline uses == this way to check a file's header against the columns it expects. shuffled holds the right names in the wrong order and fails the check, which is what you want when columns are read by position. is asks a different question. As with None, it tests whether 2 names refer to the same object. Here expected and received are separate lists that happen to hold equal items. Compare contents with ==. The last line shows that the integer 1 and the string "1" are unequal, and comparing them raises no error.

< and <= use the same walk, as do > and >=. Python finds the first position where the items differ, and that single pair decides the whole comparison; everything after it is ignored. Strings compare the same way: "apple" < "apricot" is settled at the third letter, where p comes before r.

The function in the animation does by hand what < does for you. In the first call, position 0 holds 3 on both sides, position 1 holds 9 against 10, and 9 is smaller, so the left list sorts first. The trailing 1 and 0 are never looked at. In the second call every shared position matches, so length breaks the tie: a list that is the start of a longer list sorts before it.

Compared as strings, "3.9.1" and "3.10.0" first differ at the third character. There 9 meets 1, and because the character 9 is larger, the string comparison calls 3.9.1 the newer release. Stored as lists of integers, the same versions compare 9 against 10 and come out right. The sort() method rearranges a list from smallest to largest by applying < to its items, so a list of version lists lands in release order with no extra code. Dates stored as [year, month, day] sort correctly for the same reason.

Python compares only up to the deciding position, so types further along never meet. [1, "x"] < [2, 0] is True: position 0 settles it before "x" faces 0. If the first items match, as they do in [1, "x"] < [1, 0], Python has to compare a string with an integer at position 1. That raises TypeError: '<' not supported between instances of 'str' and 'int'. == never raises this way, because items of different types count as unequal.

Many lists are stored oldest first, because that's the order items arrive in, and read newest first, because the latest entries matter most. Python offers 3 ways to flip the order. They give back different things, and choosing the wrong one usually shows up as a None or as a list you didn't mean to change.

letters.reverse() reorders the items inside letters: after the call, the same list holds e first and a last. No new list is created, and the method returns None, the value Python uses for no result.

The last 2 lines show a common bug. events.reverse() flips the list. The assignment then replaces events with None, which is what the method returns, so the data is gone. The next line that indexes events fails with TypeError: 'NoneType' object is not subscriptable. Call reverse() on a line of its own and keep using the same name.

A step of -1 walks from the end toward the front. With both ends left out, [::-1] visits every item backwards and returns a new list, leaving events in its original order. With a negative step the defaults swap: an empty start means the last item and an empty stop means past the first. So events[2::-1] starts at position 2 and walks back to the front, and events[-1:-3:-1] takes positions -1 and -2, stopping before -3.

reversed(events) hands out the items from last to first, one per pass of a for loop, without building a reversed list and without changing events. It reads the original list as the loop runs, which makes it the cheapest choice when you only walk backwards once. Printing it directly shows a description of an object instead of the items; wrap it in list() when you need a real list.

Searching a list means asking whether a value is there and, if it is, where it sits and how many times it appears. in checks for the value, while index() finds its position and count() counts it. Underneath, they work the same way: start at position 0 and compare each item with == until the answer is known.

in returns True or False, and not in returns the opposite, which reads well in a guard clause. index() returns the position of the first match only, so the second "late" at position 5 is never reported. count() returns how many items equal the value, and 0 when none do.

The animation shows the work behind every search. Finding "failed" takes 5 checks because it sits at position 4, and the loop stops at the first match. A value near the front costs a few checks; a value near the end, or one that is missing, costs a check for every item. On a list of a few hundred items nobody notices. Inside a loop that tests each incoming record against a list of 1,000,000 IDs, every missing ID costs 1,000,000 comparisons, and a later lesson covers structures built for fast lookups.

statuses.index("missing") raises ValueError: 'missing' is not in list, which stops the program. Check with in first, or use a loop that returns None when nothing matches, as the animation's function does. index() also accepts a starting position: statuses.index("late", 3) begins searching at position 3 and returns 5, the second late batch.

The guard in find() turns a crash into a None the caller can test with is None, at the cost of scanning the list twice when the value is present. The enumerate() loop at the end collects every matching position, which index() alone cannot do.

in and index() look for one exact value. To find the first item that meets a condition, such as the first day with fewer than 100 rows, write the loop yourself and stop with break. The loop's else runs only when the loop finished without breaking, which is exactly the not-found case.

Every search compares with ==, so the equality rules from comparing lists decide what matches. The float 1.0 equals the integer 1 and is found. The string "1" doesn't equal the integer 1, which is how IDs read from text quietly fail to match IDs stored as numbers. An item can itself be a list, and [2, 5] matches only a whole item equal to it, so 2 isn't found even though it appears inside an item. On a list of strings, in matches whole items: "ok" is not found in ["ok_retry", "okay"], while in on a single string finds substrings.