Passing Arguments to Functions

One List, Two Names

Suppose a program gives a second variable the value of an existing list by writing b = a. It is easy to imagine that Python creates a second list. In fact, both names refer to one underlying object. The second name, b, is an alias for a. This distinction becomes especially important when the object is passed into a function and the function changes the object.

Tracing a List Mutation

The important point is that the operation changes the list object, not merely the name used to reach it. Since there is only one underlying list, every alias reveals the updated contents. This is correct Python behavior, although it can be surprising when a programmer expected b = a to make a copy.

What Function Parameters Receive

When an object is passed to a function, the function parameter becomes another variable name associated with that object. If the argument is a list and the function mutates that list, the caller can observe the mutation through its original variable name. The parameter and the caller's variable can therefore act as aliases while the function is working with the object.

To reason about a function call, ask two questions: which object does the argument name refer to, and does the function mutate that object? If the answer to both questions involves the same mutable list, the caller's list can change as a result of the call. The function parameter is another route to the list, not automatically an independent list.

Lists and Strings Behave Differently

Aliasing is most troublesome with mutable objects. Lists are mutable, so their contents can be changed in place. If two names refer to the same list, a modification through one name is visible through the other. Strings are immutable, so their contents cannot be changed in place. An operation that appears to modify a string creates a new string instead.

Preventing Shared-List Bugs

The safest approach is not to avoid assignment altogether. Instead, be intentional about whether two names should share one mutable list. If two independent lists are required, create an explicit copy rather than assigning the original list directly.

Two list-copying strategies given in the source are slicing, as in new_list = old_list[:], and the list constructor. Either strategy creates an independent list when that is what the program requires. The key debugging question is whether the second variable should share future mutations or should preserve its own contents.

Mistakes with Aliases

• Assuming b = a copies a list.

  Direct assignment creates another reference to the object; it does not create an independent list.

  Fix: Use slicing or the list constructor when independent lists are needed.

• Expecting a list mutation to affect only the variable used for the mutation.

  There is only one underlying mutable object.

  Fix: Trace the object, not just the variable name, and check whether the names are aliases.

• Treating a string operation as if it mutated the original string.

  Strings are immutable and cannot be changed in place.

  Fix: Keep track of which name is rebound and which name still refers to the original string.

• Avoiding all assignment instead of deciding intentionally whether sharing is wanted.

  Aliasing is not inherently a Python error; it is a source of unexpected behavior when shared mutable state was not intended.

  Fix: Use direct assignment for intentional sharing and an explicit copy for independent list data.

Practice the Trace

1. To solve an aliasing trace, follow the object references in order. Identify the original object, note every variable or parameter that refers to it, and then determine whether an operation mutates that object or rebinds one name to a new object.