Ask what stays connected after a copy

Ask what stays connected after a copy

An AI explanation of a copied Python object can sound clear while leaving out the most important relationship: which later changes can still appear through both names? Before accepting the explanation, identify the outer container, the values it refers to and the exact operation performed. A new outer dictionary does not by itself mean that every nested list is independent. Equal displayed contents also do not establish that two names refer to the same object. These are separate questions that deserve separate checks.

This guide uses original small in-memory examples with ordinary dictionaries, lists and strings. The fictional identifiers describe teaching inputs, not client records or a production application. No AI response, live configuration, file, database or network service was evaluated. The primary Python 3.12 copy documentation was read October 30, 2026 for its limited distinction between assignment, shallow copying and deep copying. The linked documentation displays maintenance version 3.12.16; the local checks use Python 3.12.14. No general implementation-conformance, performance or security finding follows from these examples.

The reading task is to reconstruct a small object relationship before predicting a specified change. That makes it different from reconciling two record lists or reading a ChainMap view. Those tasks concern supplied records or layer lookup. Here the question is whether an operation created a separate outer object, preserved a nested connection or recursively copied a particular built-in structure. Keep the operation and the object relationships in the explanation instead of using the word copy as a complete specification.

Card A: a second name is not a second list

Fictional card A begins with a list containing the labels amber and blue. A second variable is assigned that same list. At that point both names refer to one list. Appending green through the second name changes that list, so inspecting the first name also shows amber, blue and green. There are two names in the written example but only one list object reached through those names. Counting the names would answer a different question from counting the objects.

An explanation should describe the assignment before describing the append. Assignment establishes the connection that makes the later result understandable. Saying that Python updated the original because it noticed matching contents is misleading. The two names were already connected to the same object. Another separately created list with the same initial labels would not acquire the append merely because its contents compared equal before the operation. Preserve reference relationships rather than attributing behavior to visual similarity.

Next, the fictional second variable is rebound to a new list containing violet. The first variable still refers to the earlier three-label list. Rebinding a name changes what that name refers to; it does not remove the earlier list's green entry. This second step is useful because the same variable name appears in both operations. Appending through it and assigning a different object to it are different actions. A summary that calls both actions changing the variable loses the distinction needed to predict the result.

A bounded AI request can ask for the list reached by each name after each step and whether the two names refer to the same object at that point. Check those two outputs independently. The final lists have different contents, but that observation alone does not explain why. The explanation should trace the original assignment, the append on the shared object and the later rebinding. This is a small Python relationship exercise, not a model evaluation or evidence that an actual application retained the intended state.

Card B: a shallow dictionary copy separates the outer mapping

Fictional card B begins with a dictionary whose title is draft and whose tags value is a list containing amber. A shallow dictionary copy creates another outer dictionary. Changing the copy's title field to reviewed leaves the original title at draft. In this example, replacing the value associated with a key happens in the separate outer mapping. That is the relationship the title check establishes. It does not establish independence for every value stored inside those mappings.

Both dictionaries initially refer to the same nested tags list. Appending blue through the copy's tags value therefore makes both dictionaries show amber and blue under tags. The outer dictionaries remain different objects while the nested list is shared. These two facts are compatible. A useful explanation names both levels explicitly instead of saying either that the dictionaries are completely independent or that the copy is exactly the original. Each of those broad descriptions would conceal part of the authored structure.

Replacing the copy's entire tags value with a new list containing green is different from appending to the shared list. After that replacement, the original tags remain amber and blue, while the copy's tags are green. The operation changed an association in the copied dictionary. It did not clear the earlier shared list. This is a useful pair of examples to place beside an AI-generated claim that changing a nested field always changes both copies. The verb changing needs an exact operation.

Record three checkpoints: separate outer dictionaries immediately after copying, shared tags before replacement and separate tags after replacement. If you ask an assistant for a diagram, require those checkpoints in separate panels. A single diagram labelled after copying cannot also describe the later replacement without showing which moment it represents. Object relationships can change across the sequence, so a correct starting diagram is not a complete explanation of the final state.

Card C: list slicing does not recursively separate nested lists

Fictional card C begins with a list containing two nested lists: the first holds amber and the second holds blue. Taking a full slice makes a new outer list with references to those nested lists. Appending a third nested list containing green to the sliced outer list gives the slice three entries while the original outer list still has two. That difference checks the independence of the outer list's membership. It says nothing yet about the contents of the first two nested lists.

Append copper to the first nested list reached through the slice. The first nested list reached through the original now also contains amber and copper. The operation reached a shared inner object. This result does not contradict the earlier observation that the outer lists had different lengths. The outer membership and the inner contents are different parts of the structure. Keep both observations in a note so a later summary does not compress them into the false claim that slicing either copies everything or copies nothing.

An assistant can explain this example using a two-level table. The first level lists each outer container and its entries. The second identifies which entries point to the same inner list. Use explicit teaching labels for those inner objects rather than relying on their displayed contents. Two lists can happen to display amber while remaining separate, and one shared list can later display amber and copper. The content is an observation at a moment; the reference relationship explains which edits are connected.

This example is intentionally small and uses ordinary built-in lists. It does not test custom sequence classes, array libraries, memory-mapped storage or a data-processing framework. If your real source uses one of those objects, preserve its type and operation when asking for help. A familiar slice symbol does not license importing this exact behavior into every library. First identify the actual object and its documented contract, then design a check that fits the question you need to answer.

Card D: inspect a deep copy at the levels actually present

Fictional card D uses a dictionary with title draft and a nested list of stages. The initial stages are collect and review. A deep copy is made using the copy module. Appending record to the copied stages leaves the original stages at collect and review while the copied stages become collect, review and record. The outer dictionaries are separate, and the relevant nested stages lists are also separate. The checks name these particular objects rather than claiming that all conceivable state has been isolated.

The word deep should prompt a careful question about the supplied object graph, not a universal promise about an application. This card contains ordinary strings in an ordinary list inside an ordinary dictionary. It contains no open file, socket, database handle, custom copying hook or external service. Copying the dictionary does not demonstrate how any of those absent things would behave. A reader can understand the specific nested-list result without treating it as proof of a complete application snapshot.

Ask an assistant to explain the difference between card B and card D using the same concrete operation: append to the nested list. In card B, the shallow copy retains the shared nested tags connection. In card D, the relevant copied stages list is separate. Keep the changing field names visible so the comparison remains attached to the actual inputs. Do not imply that the two cards are measurements of speed, resource use or suitability for a real workflow. They are relationship examples.

Also separate copying from acceptance. A copied title of reviewed is merely a string if that string is present in the authored data. It does not mean that a person performed a review or approved the copied object. This is especially useful when an AI assistant is asked to explain code with state-like labels. The code's data and the operating significance assigned to those data are different matters. This guide supplies neither a production approval policy nor evidence that such a policy was followed.

Card E: a deep copy can preserve sharing inside its new graph

Fictional card E creates one list containing amber and places that same list under two keys, left and right, in a dictionary. Both keys refer to the same original inner list. A deep copy produces a new outer dictionary with a copied inner list. Within the copied dictionary, left and right still refer to the same copied inner list. That inner list is separate from the original inner list. The internal sharing relationship survives while the connection to the original has changed.

Append blue through the copied dictionary's left value. Its right value also shows amber and blue because those two copied associations reach the same copied list. The original dictionary's left and right values still show only amber. A sentence that says deep copying removes all shared references would predict the wrong relationship inside the copy. A sentence that says the copied left and right are connected to the original would also be wrong for this authored built-in structure.

The useful distinction is between sharing across the original and copied graphs and sharing within one graph. Name the original inner list and the copied inner list separately. Then draw the two associations in each outer dictionary. The resulting explanation has two outer dictionaries and two inner lists, with two associations to each inner list. Counting four keys would not establish four inner lists. A relationship-aware count answers the actual structural question rather than a count of written access paths.

This example is a compact way to review a generated diagram. If the assistant draws a separate copied list for each copied key, its diagram no longer matches the demonstrated relationship. If it draws one list reached by both original and copied dictionaries, it also changes the demonstrated relationship. Check the named connections directly. The fact that all lists initially contain amber makes the example useful: equal displayed contents cannot tell you which diagram is correct without checking references.

Card F: an unknown copying operation leaves the later result unresolved

Fictional card F supplies an original dictionary with a nested tags list containing amber, but the copying operation is unspecified. The card does not tell you whether a second name is an alias, a shallow copy or a deep copy. A proposed later append through the second object's tags therefore has no single established effect on the original from the supplied description. Preserve that missing operation in the reading note instead of choosing whichever interpretation makes the explanation simplest.

Three separately labelled hypothetical completions illustrate the gap. If the second name aliases the original dictionary, the append appears through the original. If the second object is a shallow copy of the outer dictionary, the shared nested list still makes the append appear through the original. If it is a deep copy of this ordinary built-in structure, the append affects the copied nested list and leaves the original tags at amber. The alternatives show dependence on an input; they do not recover the missing source operation.

The alias and shallow-copy alternatives happen to give the same original tags after this append. That does not make the two alternatives structurally identical. Replacing an outer dictionary association would distinguish them in a different check. Choose the check around the question you are trying to settle. One observed result may be compatible with multiple object relationships. A useful explanation states what the demonstrated change distinguishes and what remains unresolved, rather than treating one matching output as a complete reconstruction.

Keep the original unknown card unchanged after discussing those alternatives. A later summary should not turn the first hypothetical branch into the actual operation. An AI drafting request can explicitly ask for separate known-input and hypothetical sections, with the unresolved conclusion repeated after the alternatives. This helps a reviewer identify the evidence boundary. It does not test whether any model will reliably follow that instruction, because no model output is part of the fictional fixture.

Build a small before-and-after note

Start a copying note with the exact initial values and their nesting. Identify whether two access paths reach the same inner object before the operation. Then write the exact operation, including whether it is assignment, a named copying call, a slice, an append or replacement of a dictionary value. Finally record the displayed values and relevant identity relationships after the operation. This order makes each prediction traceable to the structure that supports it.

Use object labels that are separate from business identifiers. A fictional record code such as EX-REC-1 is stored data; it is not the Python identity of its containing dictionary. Two separate dictionaries may contain the same code, while two names may refer to one dictionary containing that code. Copying a code does not establish a second real entity, and sharing a dictionary does not establish that two real entities are the same. Keep the programming relationship distinct from any claim about the records' meaning.

A bounded AI request can ask the assistant to fill a before-and-after table for the supplied code and explain each changed connection in one sentence. Ask it to avoid assuming custom methods or external systems that are not present. Then verify its table against the small example. If the actual source includes custom objects or a library container, include that context rather than requesting a generic Python answer. Missing type information can be as important as a missing copying operation.

Prefer one specified change at a time when diagnosing a misunderstanding. If you append to a nested list and replace an outer key before inspecting either object, the final display may conceal which operation caused a particular difference. The teaching cards separate those moments so each observation has a clear role. In real debugging, preserve the original sequence while adding checkpoints; do not rewrite the program into a cleaner-looking sequence and then describe the new sequence as evidence about the old one.

Keep the verification claim as small as the example

The companion checks inspect the authored lists and dictionaries, compare their contents and test selected identity relationships with Python's identity operator. They do not publish or compare raw memory addresses. Their results concern the objects created during that local run. No persisted file, serialized payload, imported configuration or application process is involved. Calling the exercise a snapshot test without those boundaries would suggest persistence and coverage that the fixture does not establish.

These checks also do not establish an appropriate copying strategy for a real system. Sometimes an application intentionally shares a resource or a nested object. Sometimes it needs separation. The desired behavior must come from the application's actual contract and evidence. This guide teaches how to read the relationships in a supplied small example so you can ask a more precise question. It does not provide a general recommendation to deep copy every object or to replace an established state-management design.

Keep runtime and source versions with the result. The linked Python documentation and local interpreter have different maintenance versions, stated at the beginning of this guide. The examples use a narrow collection of ordinary built-in structures and operations. Passing their checks does not establish every copying edge case across versions, custom classes or implementations. If a later change introduces a new object type, inspect that type's behavior and add a relevant check rather than assuming the old fixture covers it.

A useful finished reading note should let another reader reconstruct the operation and the relationships without trusting an adjective such as independent. It should say independent at which level, after which operation and for which objects. It should also identify unknown inputs and distinguish a hypothetical completion from the supplied code. Those details make an AI-assisted explanation reviewable. The prose can remain simple while its claims stay attached to the exact structure that was actually checked.

Frequently asked questions

Does assigning a list to another variable copy the list?

In card A it creates another name for the same list. Appending through that second name appears through the first name. Rebinding the second name later to a different list does not undo the earlier append. Read assignment, mutation and rebinding as separate operations, then inspect the names' relationships at each checkpoint rather than counting variable names as separate objects.

What does a shallow dictionary copy leave shared?

Card B creates a separate outer dictionary while retaining a reference to the supplied nested tags list. Replacing the copy's title does not change the original title, but appending to the shared nested list appears through both dictionaries. Replacing the copy's entire tags association with a new list changes that later relationship. The example checks these particular levels and operations, not every possible object type.

Does a full list slice separate nested lists?

Card C makes a new outer list while retaining the two supplied inner-list references. Adding a third outer entry changes only the sliced outer list's length, while appending to the shared first inner list appears through both access paths. Keep the outer membership and inner contents separate. These are ordinary built-in list examples, not findings about a different sequence library.

Does deep copying guarantee complete application isolation?

These fixtures establish no such guarantee. Card D checks separate outer dictionaries and a particular copied nested stages list. It contains no custom copying hooks, open files, sockets or external systems. A successful nested-list check does not establish a durable snapshot, security boundary or production application's intended behavior. Review the actual types and contract before drawing a broader conclusion.

Can two values inside a deep copy still refer to one list?

Yes in card E: the copied left and right associations reach the same copied inner list, which is separate from the original inner list. Appending through the copied left value also appears through the copied right value while leaving the original unchanged. Distinguish internal sharing within the copy from a connection between the original and copied structures.

What if the source says copied without naming the operation?

Keep the operation unresolved. Card F compares alias, shallow-copy and deep-copy alternatives without adopting any of them as the missing source operation. Some alternatives produce the same result for one append but differ structurally or under another operation. Ask for the actual code or contract, and retain the unknown after illustrating the alternatives. No model response or real application result was evaluated here.