460 Python Developer Interview Questions & Answers

any() returns True when at least one item is truthy. all() returns True only when every item is truthy. Both stop as soon as the result is known. For an empty iterable, any() returns False and all() returns True.

Use any() when one truthy result is enough. Use all() when every result must be truthy. Each function accepts an iterable and applies normal Python truth testing to its items. Values such as False, None, zero, an empty string, and an empty collection are falsy. Other objects are usually truthy unless their type defines different truth behavior.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

any() returns True as soon as it reads one truthy item. It returns False if every item is falsy or the iterable is empty. all() returns False as soon as it reads one falsy item. It returns True if every item is truthy. It also returns True for an empty iterable because no falsy item breaks the condition.

This early stopping is called short circuit evaluation. If the result is found after k items, the time cost is proportional to k. In the worst case, every item is checked. The functions use constant extra memory while iterating, not counting the iterable itself. With an infinite iterable, a call may never finish if no decisive item appears. Truth testing can also raise an exception if an object defines faulty truth behavior. Use these functions for clear condition checks, but not when you need the matching item, the failing item, or a count.

A common mistake is reversing the meanings of any() and all(). Another mistake is thinking they accept only literal True and False values, even though they apply Python truth testing to every item. Developers may incorrectly expect all() on an empty iterable to return False. Another mistake is creating a complete list before the call when a generator expression could reduce memory use and avoid unnecessary work. It is also incorrect to use these functions when the program must return the exact item that passed or failed.

Begin with the direct rule. Say that any() needs one truthy item, while all() needs every item to be truthy. Then mention short circuit evaluation and the empty iterable results. These details show that you understand both the visible result and the runtime behavior.

The main difference is that a list is mutable, while a tuple is immutable. A list can add, remove, replace, or reorder items after creation. A tuple cannot replace, add, or remove its stored item references. Lists normally use square brackets and are best for collections that change. Tuples use commas, often inside parentheses, and are best for fixed groups of values. Lists are not hashable. A tuple can be hashable when every item inside it is hashable. In CPython, tuples also usually use less memory than lists with the same items.

Use a list when the collection must change. Use a tuple when the collection represents a fixed group of values.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

A list is mutable. Mutable means the same list object can be changed after it is created. You can append an item, remove an item, replace an item by index, reverse the list, or sort it in place.

A tuple is immutable. Immutable means Python does not allow you to replace, add, or remove the item references stored in that tuple after creation. A tuple therefore has no append, extend, remove, pop, reverse, or sort method.

A list normally uses square brackets. For example, tasks = ["read", "test"]. A tuple is created by commas, although parentheses are commonly used for clarity. For example, point = (10, 20). The comma is important. A one item tuple must include a trailing comma. single = (10,) is a tuple, while single = (10) is the integer 10.

Lists and tuples support many of the same read operations. Both support indexing, slicing, iteration, len, membership checks with in, count, index, concatenation, and repetition. Concatenation requires matching sequence types. A list can be concatenated with another list. A tuple can be concatenated with another tuple.

Lists also support operations that change the existing object. Tuples do not. An expression such as values = values + (30,) does not change the old tuple. It creates a new tuple and makes the variable values refer to the new object.

A list is not hashable, so it cannot be a dictionary key or a set element. Hashable means an object has a hash value that remains suitable for lookup during its lifetime. A tuple can be hashable, but only when every item inside it is hashable. For example, (10, 20) can be a dictionary key. A tuple such as ([10], 20) cannot be a dictionary key because the inner list is not hashable.

Tuple immutability is shallow. The tuple cannot replace an item reference, but a mutable object stored inside the tuple can still change. For example, data = ([1, 2], "ready") cannot assign a new value to data[0]. However, data[0].append(3) is allowed because that operation changes the inner list, not the tuple structure.

Assignment does not copy a list or a tuple. If two variables refer to the same list, a mutation through one variable is visible through the other. Two variables can also refer to the same tuple, but the tuple structure cannot be mutated. Creating a separate list requires an explicit copy when independent mutation is needed.

In CPython, a tuple usually uses less memory than a list containing the same item references. A list commonly keeps extra capacity so later append operations can be efficient. A tuple has a fixed size and does not need growth capacity. Exact memory use and small speed differences depend on the Python implementation and version, so type choice should be based mainly on behavior and meaning.

In production code, lists are useful for active tasks, collected records, request results, validation messages, and other collections that change. Tuples are useful for coordinates, fixed return values, compound dictionary keys, and records whose positions have stable meaning. A tuple also communicates intent by showing that the group is not expected to change.

First, decide whether the collection must change after creation. Use a list when items must be added, removed, replaced, reordered, or sorted in place.

Second, decide whether the values form one fixed record. A coordinate such as (10, 20) is a good tuple because each position has a stable meaning.

Third, check whether the value must be used as a dictionary key or set element. A list cannot be used. A tuple can be used only when every item inside it is hashable.

Fourth, inspect any nested values. A tuple does not make an inner list, dictionary, or set immutable.

Fifth, check whether assignment or copying matters. Assignment creates another reference to the same object. Make an explicit copy when two lists must change independently.

Finally, consider memory and small runtime differences only after choosing the correct behavior. In CPython, tuples are usually smaller, while lists provide the flexibility required for changing data.

The code creates a list named tasks and a tuple named point. It changes the list by appending an item and replacing the first item. It reads values from the tuple without changing its structure. It then uses the tuple as a dictionary key because both integers inside it are hashable. Finally, it creates a tuple containing a list and changes the inner list. This demonstrates that tuple immutability is shallow. The tuple still refers to the same inner list, but that list can mutate.

A common mistake is saying that a tuple and everything inside it are immutable. A tuple can contain a list, dictionary, set, or another mutable object. The tuple cannot replace that object, but the inner object can still change.

Another mistake is assuming every tuple is hashable. A tuple is hashable only when every item inside it is hashable. A tuple containing a list is not hashable.

Some developers forget the comma in a one item tuple. The expression (10) is an integer. The expression (10,) is a tuple.

Another mistake is believing tuple concatenation changes the existing tuple. It creates a new tuple and rebinds the variable.

It is also incorrect to assume assignment creates a copy. After second = first, both variables refer to the same object. This is especially important with lists because a mutation through one reference is visible through the other.

Another mistake is claiming that tuples always provide a meaningful performance improvement. Memory use and speed depend on the Python implementation and version. The main reason to choose a tuple is fixed structure and clear intent.

Finally, using a tuple for data that must change often can create repeated allocations because every structural change requires a new tuple.

Begin with mutability because it is the main difference. Then compare syntax, supported operations, hashability, memory behavior, and common use cases. Mention that tuple immutability is shallow and that a tuple is hashable only when all of its items are hashable. Finish with the practical rule: use a list for changing collections and a tuple for fixed groups of values.

A dictionary stores unique keys that map to values. A set stores unique members without attached values. I use a dictionary when I need to look up data by a key, such as a user ID mapped to a user name. I use a set when I need uniqueness, fast membership checks, or group operations. Membership in a dictionary checks keys, while membership in a set checks its members.

The practical decision is simple. Use a dictionary when one item must point to another item. Use a set when you only need unique members.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

A dictionary stores key and value pairs. For example, {101: "Asha", 102: "Sam"} maps each user ID to a user name. Dictionary keys are unique. If code assigns a new value to an existing key, Python replaces the value connected to that key.

A set stores members without attached values. For example, {101, 102} records which user IDs were visited. Set members are unique. Adding 101 again does not create a second 101.

Membership behavior is different. The expression 101 in users checks whether 101 is a key in the users dictionary. It does not search the dictionary values. To search values, code can use "Asha" in users.values(), but that normally requires checking values one by one. The expression 101 in visited checks whether 101 is a member of the visited set.

Dictionary keys and set members must be hashable. Hashable means Python can calculate a hash value that remains stable while the item is stored. Integers, strings, and tuples containing only hashable items are common examples. Lists, sets, and dictionaries are mutable and cannot be used directly as dictionary keys or set members.

Dictionaries preserve insertion order. Iteration visits keys in the order they were first inserted. Changing the value for an existing key does not move that key to a new position. Removing a key and adding it again places it at the end. Sets do not guarantee insertion order or any other useful business order. Code should not depend on the displayed or iteration order of a set.

Dictionaries support key lookup, value assignment, updates, deletion, and access to keys, values, and item pairs. Sets support membership checks, adding members, removing members, and group operations such as union, intersection, difference, and symmetric difference.

Some values that compare as equal may act as the same key or member. For example, True and 1 compare as equal and have the same hash. A dictionary cannot keep them as two separate equal keys, and a set cannot keep them as two separate equal members.

Use a dictionary for records indexed by ID, configuration data, counters, caches, lookup tables, and grouped results. Use a set for duplicate removal, visited items, permissions, membership checks, and comparisons between groups.

Both structures use hash table storage and keep extra capacity to support fast operations. Their exact memory use depends on the Python implementation, Python version, collection size, and stored objects. A dictionary stores references for both keys and values. A set stores member references without separate mapped values. It is not safe to promise an exact memory ratio between them.

An empty dictionary is written as {}. An empty set must be written as set(). The expression {} never creates an empty set.

First, decide whether each stored item needs an attached value. If it does, use a dictionary.

Second, if no attached value is needed, decide whether uniqueness or group comparison is important. If it is, use a set.

Third, identify what membership should mean. In a dictionary, membership checks keys. In a set, membership checks members.

Fourth, confirm that every dictionary key or set member is hashable. Do not use a list, set, or dictionary directly in either position.

Fifth, decide whether insertion order matters. A dictionary preserves insertion order. A set does not provide an order that application logic should depend on.

Finally, choose operations that match the task. Use dictionary access and assignment for mapped data. Use set union, intersection, difference, or membership checks for groups of unique items.

The example uses the same user IDs to show the difference between the two structures. The users dictionary maps each user ID to a user name. Assigning a new value to key 101 changes the mapped name because dictionary keys are unique. The visited set stores only user IDs. Adding 101 again has no effect because set members are unique.

The membership examples show that dictionary membership checks keys. Searching dictionary values requires users.values(). The set membership example checks set members directly.

The example sorts sets only before printing them. Sorting gives deterministic display output, but it does not change the fact that sets themselves do not guarantee insertion order. The intersection, union, and difference operators create new sets without changing the original sets.

A common mistake is using {} for an empty set. This creates an empty dictionary. Use set() for an empty set.

Another mistake is assuming that value in my_dictionary searches dictionary values. It checks keys. Use value in my_dictionary.values() when value membership is required, and remember that this normally takes linear time.

Some developers depend on set iteration order because the order may appear stable in one run. Python does not guarantee a useful set order. Sort the members when output requires a predictable order.

Another mistake is using a list, set, or dictionary as a dictionary key or set member. These objects are mutable and not hashable.

A dictionary cannot contain duplicate equal keys. Assigning a value to an existing key replaces its mapped value. A set cannot contain duplicate equal members. Adding an equal member again has no effect.

Converting a list to a set removes duplicates, but it does not preserve a guaranteed original order. Use list(dict.fromkeys(items)) when duplicate removal and insertion order are both required.

Another mistake is assuming that equal values with different types must remain separate. For example, True and 1 act as the same dictionary key or set member because they compare as equal and have the same hash.

Start with the practical choice. Say that a dictionary stores unique keys mapped to values, while a set stores unique members only. Then explain membership behavior, ordering, hashability, one use case for each, and the average lookup cost.

append adds one object to the end of a list. extend takes an iterable and adds each item from it to the end. insert takes an index and one object, then places that object before the element currently at that position. All three methods change the existing list and return None. I use append for one object, extend for several items, and insert when a specific position is required.

The practical rule is to use append for one object, extend for every item from an iterable, and insert for one object at a chosen position.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

append accepts one object and adds it to the end. Appending [3, 4] to [1, 2] produces [1, 2, [3, 4]]. The added list remains one nested object.

extend accepts one iterable. Python reads that iterable and adds each item separately. Extending [1, 2] with [3, 4] produces [1, 2, 3, 4]. A non iterable value raises TypeError. Extending with a string adds its characters separately.

insert accepts an index and one object. It places the object before the element at that position. A large positive index places it at the end. A very small negative index places it at the beginning.

All three methods modify the same list and return None. They store references to objects rather than copying the objects themselves. The list may allocate more internal space as it grows. append is usually constant time on average. extend takes time based on the number of added items. insert may take time based on the list size because existing references may need to move.

A common mistake is using append when each item from another iterable should be added separately. This creates one nested element instead of adding the items individually. Another mistake is writing values = values.append(3). append returns None, so values then refers to None. The same return behavior applies to extend and insert. Developers may also forget that extend with a string adds separate characters. Another mistake is expecting these methods to copy mutable objects. They add object references, so later changes to a shared mutable object can be visible through the list. Repeated insert calls near the beginning of a large list can also create unnecessary performance cost.

Start with the decision rule. Say that append adds one object, extend adds each item from an iterable, and insert adds one object at a chosen index. Then use the same small list example to show that append can create a nested list while extend adds separate items. Finish by stating that all three methods modify the original list and return None.

Use remove when you know the value, pop when you know the index and need the removed value, and del when you want to delete an item, a slice, or a variable name. remove deletes the first matching value and returns None. pop removes and returns an item, using the last item when no index is given. del is a statement, so it does not return a value.

The practical choice depends on what you know and whether you need the removed value. list.remove(value) searches from the start of the list and deletes the first item that compares equal to the value. It returns None. If no match exists, Python raises ValueError. Use it when the value matters more than its position.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

list.pop(index) removes and returns the item at that index. With no index, it removes the final item. A missing item in an empty list or an index outside the valid range raises IndexError. Negative indexes are allowed when they refer to a valid position.

del is a Python statement. del items[index] removes one item. del items[start:stop] removes a slice. del name removes that name from its current scope. It does not directly destroy the object if other references still point to it.

All list removal operations change the original list. remove may scan many items before finding a match. Removing from the front or middle also shifts later items left. pop() from the end is amortized constant time in normal Python list use. These operations usually do not create a new list, although Python manages the internal list storage and may keep some allocated capacity.

A common mistake is expecting remove to return the deleted item. It returns None. Another mistake is assuming remove deletes every matching value. It deletes only the first match. Developers may also call pop on an empty list or use an invalid index without handling IndexError. Another error is treating del like a function or expression that returns a value. del is a statement. It is also incorrect to assume del name always destroys the object immediately. It removes one name binding, but other references may still keep the object alive. Removing items while iterating over the same list can also skip values or produce confusing results because indexes change.

Start with the decision rule. Say remove is by value, pop is by index and returns the item, and del deletes an item, slice, or name without returning anything. Then mention the main exceptions and explain that removing from the middle of a list requires later items to shift.

split breaks one string into a new list of smaller strings. join combines an iterable of strings into one new string and places a separator between the items. For example, "red,green,blue".split(",") returns ["red", "green", "blue"], and ",".join(["red", "green", "blue"]) returns "red,green,blue". Every item passed to join must be a string, or Python raises TypeError.

Use split when you need to break one string into parts. Use join when you need to combine strings with a separator.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

For example, "red,green,blue".split(",") returns a new list containing "red", "green", and "blue". When a separator is provided, Python cuts at each occurrence of that exact separator. Repeated separators can create empty strings. For example, "red,,blue".split(",") returns ["red", "", "blue"]. An empty separator is invalid and raises ValueError.

When split is called without a separator, Python treats runs of whitespace as one separator and ignores whitespace at both ends. This differs from split(" "), which uses one exact space and can produce empty strings.

join works in the opposite direction. The separator calls the method. For example, ",".join(["red", "green", "blue"]) returns "red,green,blue". Every item must be a string. A non string item causes TypeError.

Strings are immutable, so neither method changes the original string. split creates a new list and new substring results. join creates a new result string. Time and memory use grow with the total amount of text processed.

The first example starts with the string "red,green,blue". split uses a comma as the separator and returns the list ["red", "green", "blue"]. join then uses the same comma separator and produces "red,green,blue". The second example contains integers. Each integer is converted to a string before join because join accepts string items only.

A common mistake is calling join on the iterable, such as values.join(","). The separator must call join, so the correct form is ",".join(values). Another mistake is passing integers, bytes, or other non string items directly to join, which raises TypeError. Developers may also assume split() and split(" ") behave the same, but repeated whitespace is handled differently. Other mistakes include using an empty separator, which raises ValueError, forgetting that repeated explicit separators can create empty strings, and using simple split for structured formats such as CSV that have quoting rules.

Explain split and join as opposite operations. State that split returns a new list, join returns a new string, the separator calls join, and every joined item must be a string. Then mention one edge case, such as repeated separators or whitespace handling.

Use the raise statement when an operation cannot continue normally. I usually raise a specific built in or custom exception instance, such as raise ValueError("Age cannot be negative"). Inside an except block, raise by itself re raises the active exception and preserves its original traceback. When one error causes a new error, raise NewError(...) from original_error creates an explicit exception chain and preserves the original cause.

Use raise when an operation cannot return a valid result. The usual form is raise followed by an exception instance, such as raise ValueError("Age cannot be negative"). Python stops normal execution and searches outward for a matching except block. If no handler matches, Python ends the current program flow and prints a traceback.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Use a built in exception when its meaning fits the problem. Use a custom exception that inherits from Exception when the failure belongs to your application domain.

Inside an except block, raise with no value re raises the active exception. This keeps the original exception type and traceback. Writing raise error instead raises that exception object again from the current location and can add another traceback frame.

When converting one exception into another, use raise NewError(...) from original_error. Python stores the original exception in the new exception's __cause__ attribute and shows both errors in the traceback. Python also keeps an implicit __context__ when a new exception is raised during exception handling. Use from None only when you intentionally want to hide that context from the displayed traceback.

Raising an exception creates traceback data and unwinds stack frames, so it is slower and uses more memory than normal branching. Exceptions should represent failures, not common control flow.

The example validates an age value. A value that cannot be converted to an integer first causes TypeError or ValueError. The code converts that failure into a custom AgeInputError and uses explicit exception chaining to preserve the original cause. A negative integer raises a built in ValueError. The process_age function catches AgeInputError, adds simple logging, and uses bare raise to re raise the same active exception with its original traceback.

A common mistake is raising Exception for every failure instead of choosing a specific exception type. Another mistake is using bare raise when no exception is active, which causes RuntimeError. Developers may also write raise error when they mean to preserve the current traceback exactly, or replace a low level error without using the from clause, which makes the cause less clear. Other mistakes include catching exceptions too early, hiding unexpected errors with a broad except block, using unclear messages, and using exceptions for common branches that can be handled with normal conditions.

Explain three cases in order. First, show how to raise a specific built in or custom exception instance. Second, explain that bare raise re raises the active exception inside an except block. Third, show that raise new_error from original_error preserves the original cause. Mention that specific exception types and useful messages improve handling and debugging.

An iterator is any object that knows how to return its next value. It uses iter() and next(), and it stops by raising StopIteration. A generator is a special kind of iterator made by a function that uses yield. The main difference is that a generator creates values lazily, one at a time, without storing the whole result. That is useful for large files, streams, database rows, or pipelines where loading everything would waste memory.

The practical answer is that an iterator is the general protocol, and a generator is an easy way to create one. A protocol means a set of methods that Python expects. For iteration, Python expects an object to work with iter() and next().

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

An iterator must return itself from __iter__(). It must also define __next__(), which returns the next value. When there are no more values, __next__() raises StopIteration. A for loop uses this behavior for you. It calls iter() once, then keeps calling next() until StopIteration happens.

A generator function is a function that contains yield. When you call it, Python does not run the full function immediately. It returns a generator object. That object is also an iterator. Each call to next() runs the function until the next yield. Then Python pauses the function and remembers its local state.

The key idea is lazy evaluation. Lazy evaluation means values are produced only when they are requested. This is different from building a full list first. A list stores every value in memory. A generator can produce one value, hand it to the caller, then continue later.

This matters when data is large or continuous. For example, reading a huge log file line by line is a good generator use case. The program does not need the whole file in memory. It only needs the current line and a little state.

The tradeoff is that generators are usually single pass. Once a value is consumed, it is gone unless you save it somewhere. If you need random access, repeated passes, or the total length, a list may be clearer. So I would use generators when I want memory efficiency and streaming behavior. I would use a list when the data is small or I need to reuse it many times.

First, explain the iterator protocol. An object becomes an iterator when iter() returns an object that has next() behavior through __next__(). Second, explain how the loop stops. When __next__() raises StopIteration, Python knows there are no more values. Third, explain a generator function. A function with yield creates a generator object instead of returning all values at once. Fourth, explain lazy evaluation. The generator produces one value only when next() asks for it. Fifth, choose between them. Use a custom iterator when you need full class control. Use a generator when yield gives the same behavior with less code.

The code shows both forms. Countdown is a manual iterator because it implements __iter__() and __next__(). It raises StopIteration when the count reaches zero. countdown_generator does the same job with yield. Python saves the function state after each yield and resumes it on the next call. Both examples produce the same values, but the generator needs less manual code.

A common mistake is thinking every iterable is an iterator. A list is iterable because iter(list) returns an iterator, but the list itself is not consumed by next() directly. Another mistake is forgetting StopIteration in a manual iterator. That can make code fail or loop forever. Some candidates think a generator runs when the function is called. It actually starts when next() asks for a value. Another mistake is trying to reuse a consumed generator like a list. If repeated passes are needed, store the values or create a new generator.

Start by saying that an iterator is the protocol and a generator is a convenient iterator made with yield. Then explain iter(), next(), StopIteration, and lazy evaluation. End with the practical use case. Generators are best when the data is large, streaming, or should be processed one item at a time.

A shallow copy creates a new outer object, but it keeps references to the same nested objects. A deep copy creates a new outer object and recursively copies nested objects when needed. I use a shallow copy when sharing nested values is safe. I use a deep copy when nested mutable data must be independent.

The practical difference is what happens to nested objects. A shallow copy creates a new outer container, but its items still refer to the same objects used by the original. If a list contains another list, changing that inner list through the shallow copy is visible through the original.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

The copy.copy function performs a shallow copy. It is useful when only the outer container must be separate or when nested objects are intentionally shared.

The copy.deepcopy function recursively processes the contained objects. It creates independent copies of nested mutable objects when their copying behavior allows it. Immutable objects may still be shared because they cannot be changed. Deepcopy also keeps a record of objects it has already processed. This helps it preserve shared relationships and handle recursive structures.

A deep copy can require more processing time and memory because Python may visit much of the reachable object graph. Classes can customize copying through special methods, and some resource based objects, such as open files, should not be treated as ordinary data copies.

In production, I choose the smallest level of copying that gives the required isolation. This avoids accidental shared changes without copying more data than necessary.

The example creates a nested list and then makes a shallow copy and a deep copy. The shallow copy has a new outer list, but it shares both inner lists with the original. Appending 5 through the shallow copy therefore changes the inner list seen by the original. The deep copy has separate inner lists. Appending 6 through the deep copy therefore does not change the original.

A common mistake is assuming that a shallow copy makes every nested object independent. Another mistake is using list.copy or slicing on a nested list and expecting deep copy behavior. Developers may also use deepcopy for every object without considering its processing and memory cost. It is also incorrect to assume that deepcopy always creates a new instance for every value. Immutable objects may be shared, and classes can define custom copy behavior.

Start with the practical rule. A shallow copy separates only the outer object, while a deep copy also separates nested mutable objects when needed. Then show one nested list example and mention the processing and memory tradeoff.

Duck typing means Python code usually cares about what an object can do, not which class it belongs to. If an object supports the operation my code needs, I can use it. For example, a function can call write on any object that provides a compatible write method. This makes code flexible, but the expected behavior should still be documented and tested because missing or incompatible operations fail when they are used.

Duck typing means code accepts an object because it supports the behavior the code needs. The object does not have to inherit from one required class. For example, a function that calls writer.write can work with a file object, an in memory stream, or a custom writer. They are compatible because each provides a suitable write method.

1. Should I focus on Python language behavior, or also explain the runtime and standard library?
2. Which Python version and execution environment should I assume?
3. Would you like a small code example together with production tradeoffs and edge cases?

Python normally checks this when the operation runs. It looks up write on the object. If the method exists, accepts the supplied arguments, and behaves as expected, the call works. If write is missing, Python raises AttributeError. If its call signature is incompatible, Python can raise TypeError.

Duck typing is useful for reusable functions, testing, adapters, iterables, context managers, and file like objects. Its main limitation is that the required behavior can be unclear. A Protocol can document the expected methods for static type checkers without forcing inheritance. An abstract base class is useful when explicit inheritance, shared code, or runtime membership rules are needed.

Duck typing itself does not copy the object or create a replacement object. Its cost is the normal attribute lookup and method call. In production, use small interfaces, clear names, type hints, focused tests, and useful boundary validation.

The example defines save_message without checking the concrete class of its argument. The function only calls write because that is the behavior it requires. FileWriter and MemoryWriter are unrelated classes, but both work because each provides a compatible write method. BrokenWriter does not provide write, so Python raises AttributeError when the call is attempted. The Writer Protocol documents the expected method for static type checking. It does not change the runtime method call or force the classes to inherit from Protocol.

A common mistake is saying duck typing means Python has no types. Python objects still have types. The point is that code can accept different types when they support the required behavior. Another mistake is checking every object with type or isinstance even when the needed operation is enough. A matching method name is also not a complete guarantee. The method must accept compatible arguments and follow the expected meaning. Another mistake is believing Protocol changes runtime behavior. It mainly helps static type checkers unless separate runtime checking is added. Broad exception handling can also hide defects, so catch errors only where the program can respond usefully.

Start with the practical rule that Python uses supported behavior rather than requiring one parent class. Give one small write example. Then explain that missing methods fail at runtime and that Protocol or an abstract base class can make the expected interface clearer.