460 Python Developer Interview Questions & Answers

The main difference is what Python binds automatically. An instance method receives the current object as self when accessed through an instance. A class method receives the class as cls, including a subclass used for the call. A static method receives nothing automatically. I use an instance method for object state, a class method for class aware behavior or alternative constructors, and a static method for a related helper that needs neither object nor class state.

Choose the method type by deciding what the operation needs. A normal function defined in a class acts as an instance method. When it is accessed through an instance, Python creates a bound method that supplies that instance as self. When it is accessed through the class, no instance is supplied, so one must be passed explicitly if the function is called.

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 class method uses the classmethod decorator. Python supplies the class as cls whether the method is accessed through the class or an instance. If a subclass performs the access, cls is that subclass. This makes class methods useful for alternative constructors and behavior that must respect inheritance.

A static method uses the staticmethod decorator. Python returns the stored function without supplying self or cls. It is useful for a helper that belongs conceptually with the class but needs no object or class state.

Binding does not copy the object or class data. Instance and class method access can create a small temporary bound method object. This cost is normally minor. Use module functions instead of static methods when the helper is not closely related to the class.

The example uses a base class and a subclass. The instance method reads data from one object through self. The class method creates an object by calling cls, so calling it through AdminUser creates an AdminUser object and preserves inherited behavior. The static method validates a value without receiving self or cls. The final class level call also shows that an instance method is not given an object automatically when it is accessed through the class.

A common mistake is forgetting self in an instance method or cls in a class method. Another mistake is believing that self and cls are Python keywords. They are strong naming conventions, but the binding behavior depends on the method form, not the parameter name. Developers may also use a static method for an alternative constructor, which prevents Python from supplying the subclass automatically. Another mistake is assuming that accessing an instance method through the class supplies an instance. It does not. A caller must provide the instance explicitly. It is also unnecessary to place every helper inside a class. A general helper may be clearer as a module function.

Start with what Python supplies automatically: an instance, a class, or nothing. Then explain that inherited class methods receive the subclass used for access. Finish with one practical use case for each method type.

Python uses the method resolution order, or MRO, to decide which class supplies an attribute or method when inheritance is involved. It calculates one consistent order with C3 linearization and exposes it through ClassName.__mro__ or ClassName.mro(). The super function continues with the next class in that order, not always the direct parent. This is why cooperative multiple inheritance requires compatible method signatures and careful super calls.

Python uses the method resolution order, or MRO, to decide which class supplies an attribute or method when inheritance is involved. For class lookup, Python checks classes in the MRO and uses the first matching definition. Normal instance lookup rules still apply, so an instance attribute or descriptor can affect the result before a class attribute is returned.

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 calculates the MRO when the class is created by using C3 linearization. In practical terms, the result preserves the parent order written in the class definition, keeps every parent before its own parents, and produces one consistent order without repeating a class. Python raises TypeError if no valid order exists.

You can inspect the order with ClassName.__mro__, which is a tuple, or ClassName.mro(), which returns a list. The super function continues after the current class in that MRO. It does not simply call a fixed parent.

Cooperative inheritance works when each nonterminal override calls super once and compatible methods accept compatible arguments. A final method may intentionally end the chain. The MRO is stored on the class, so Python does not recalculate it for every call. Lookup may inspect several classes, while the stored order uses memory proportional to the number of classes.

The example uses a diamond inheritance structure. Class D inherits from B and C, while both B and C inherit from A. Python calculates the order D, B, C, A, object. Calling D().process() starts in D. The super call in D continues to B. The super call in B continues to C, not directly to A, because C is next in the MRO. The super call in C then continues to A. Class A intentionally ends this custom method chain because object does not define process. Each custom implementation therefore runs exactly once.

A common mistake is assuming that super always calls the direct parent. It continues with the next class after the current class in the MRO. Another mistake is calling a parent method directly, such as A.process(self), because this can skip another class or run a shared ancestor more than once. A class can also break the cooperative chain by omitting super too early, calling it more than once, or using arguments that the next method cannot accept. Developers may also forget that changing the order of parent classes can change the MRO and therefore change runtime behavior.

Begin with the practical rule that Python searches classes in MRO order and uses the first matching definition. Then explain that C3 linearization creates the order, show how __mro__ exposes it, and state that super moves to the next class in that order. Use a small diamond example to prove that super does not always mean direct parent.

Python first checks sys.modules for the fully qualified module name. If the module is already there, Python normally reuses the cached module object. Otherwise, finders try to locate it, usually through sys.meta_path. The standard path finder searches sys.path for a top level module or the parent package path for a child module. A loader then creates the module when needed and executes its code. Python places the module in sys.modules before execution finishes, which prevents repeated loading but can expose a partly initialized module during a circular import.

Python first checks sys.modules, a dictionary that maps fully qualified module names to module objects. If the requested name is present, Python normally reuses that object instead of finding and executing the module again.

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 a new import, Python asks the finders in sys.meta_path for a module specification. The standard path finder searches sys.path for a top level module. For a child module, it searches the parent package path, usually stored in __path__. The specification identifies details such as the loader and module origin.

The loader creates the module when needed and executes its code. Before execution, Python places the module in sys.modules. This early insertion prevents endless repeated loading and lets recursive imports refer to the same object. If execution fails, Python removes the failing module entry, although modules imported successfully as side effects can remain cached.

A circular import fails when one module reads a name from another before that name has been created. This may cause an ImportError or AttributeError involving a partly initialized module. In production, keep package boundaries clear, avoid unnecessary import time work, and move shared definitions into a separate module when two modules depend on each other.

A common mistake is saying that Python simply searches every directory on the computer. Python uses registered finders, and the standard path based finder searches configured locations. Another mistake is saying that every import executes the module again. Successful imports are normally reused from sys.modules. Developers may also assume that importing a package automatically imports every child module, which is not generally true. A local file can shadow a standard library or installed module when it has the same name. Editing sys.path inside application code can hide packaging problems. Moving an import into a function may delay a circular dependency, but it does not always remove the underlying design problem. Deleting a module from sys.modules also does not guarantee that old references to the previous module object disappear.

Explain the process in runtime order. Start with sys.modules. Then describe sys.meta_path, the module specification, the loader, sys.path for top level modules, and the package path for child modules. Finish by explaining that early insertion into sys.modules can expose a partly initialized module during a circular import.

A decorator receives a callable and returns the object that will replace it. Python applies the decorator when it executes the function definition. The at syntax is equivalent to assigning the result of the decorator back to the function name. A wrapper can run logic before or after the original call. In production code, I normally use functools.wraps so tools can still find the original name, documentation, and wrapped function.

A decorator changes what a function name refers to. Python can do this because functions are first class objects. They can be passed to another function and returned as 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?

When Python executes a decorated function definition, it creates the original function first. It then evaluates the decorator expression, passes the function to the decorator, and assigns the returned object to the original name. Therefore, applying @logger to process is equivalent to process = logger(process). Decoration happens when that definition is executed, which is often during module import, not on every later call.

A common decorator returns a wrapper function. The wrapper runs extra logic, calls the original function, and returns its result. It often accepts *args and **kwargs so it can forward different arguments.

A decorator with arguments needs three levels. The outer function receives configuration, the next function receives the target callable, and the wrapper handles each call.

functools.wraps copies useful metadata and sets __wrapped__. It does not remove the extra call cost. A closure can also keep captured objects alive while the decorated function remains reachable.

The example uses a decorator factory named log_calls. The outer function receives the label argument. It returns the real decorator, which receives the target function. The decorator returns a wrapper that accepts any positional and keyword arguments. functools.wraps preserves important metadata and adds a __wrapped__ reference to the original function. Each call prints the configured label and function name, calls the original function once, and returns its result unchanged.

Common mistakes include calling the target function while creating the decorator instead of inside the wrapper, forgetting to return the wrapper, and forgetting to return the original result. A wrapper with fixed parameters may fail for functions with different call signatures, so forwarding *args and **kwargs is common. Omitting functools.wraps causes misleading names and documentation. Another mistake is assuming wraps gives the wrapper the exact runtime signature of the original function. It preserves metadata and sets __wrapped__, but the wrapper itself still uses its declared parameters. Decorators can also be applied in the wrong order because stacked decorators are applied from the bottom upward.

Begin with the replacement rule. Say that @decorator above a function is equivalent to assigning decorator(function) back to the same name. Then explain the wrapper, when decoration occurs, why functools.wraps matters, and why decorator arguments require one extra function level.

A closure is an inner function that keeps access to names from an enclosing function even after the enclosing function has returned. Python keeps references to those captured names rather than copying their current values. This causes late binding, so functions created in a loop may all read the final loop value. I can save each current value with a default argument, and I use nonlocal only when the inner function must rebind a captured name.

A closure is created when an inner function refers to a name from an enclosing function scope and the inner function is returned or stored for later use. Python keeps the captured name in a closure cell, so the inner function can still access it after the outer call has finished.

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 captured object is not copied. The closure keeps a reference to it. Python also uses late binding for captured names. The value is normally read when the inner function runs, not when its function object is created. This matters in loops because several functions may share the same loop variable and later return its final value. A common fix is a default argument because its value is evaluated each time the def statement runs.

Reading a captured name needs no keyword. Mutating a captured mutable object also needs no nonlocal statement. However, assigning a different object to a captured name is rebinding, so nonlocal is required. It targets the nearest enclosing function scope and cannot target a global name.

Closures are useful for decorators, callbacks, factories, and small private state. Creating or calling one is normally constant time, apart from the work inside it. Captured references use memory and may keep large objects alive. For complex state, a class is often clearer.

The code demonstrates the three behaviors required by the question. make_multiplier captures factor and reads it after make_multiplier has returned. build_functions stores the current loop value in a default argument, so each returned function has its own saved value instead of reading one shared loop variable later. make_counter uses nonlocal because increment assigns a new integer object to count. The examples print 12, then the list 0, 1, 2, and then the counter values 1 and 2.

A common mistake is assuming that a closure stores an independent frozen copy of every captured value. It normally stores access to a closure cell, so late binding can make loop functions share the final loop value. Another mistake is assigning to a captured name without nonlocal. Python then treats that name as local to the inner function, which can cause UnboundLocalError if it is read before assignment. Developers also sometimes use nonlocal when only mutating a captured list or dictionary, even though rebinding is not occurring. A closure can also keep captured objects alive longer than expected, which matters when those objects use significant memory or hold external resources.

Begin with the main rule that a closure keeps access to an enclosing scope. Then explain that Python captures names through closure cells and uses late binding. Use a loop example to show the problem, explain the default argument fix, and finish by stating that nonlocal is needed for rebinding but not for reading or mutating a captured object.

A context manager implements the with statement through __enter__ and __exit__. Python calls __enter__ before the block and assigns its return value to the name after as. If __enter__ succeeds, Python calls __exit__ when control leaves the block. When an exception occurs, __exit__ receives its type, value, and traceback. Returning True suppresses that exception. Returning False or None lets it continue. The contextlib.contextmanager decorator provides the same protocol through a generator that performs setup before yield and cleanup after yield.

The practical purpose of a context manager is to prepare a resource and release it reliably. Python first evaluates the expression after with and obtains a context manager. It calls __enter__, and the returned value becomes the value after as. If __enter__ raises an exception, the block never starts and __exit__ is not called.

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?

After __enter__ succeeds, Python runs the block. When control leaves the block normally, Python calls __exit__ with three None values. If the block raises an exception, Python passes the exception type, exception object, and traceback. Returning True tells Python that the exception was handled. Returning False or None allows it to continue.

The contextlib.contextmanager decorator offers a generator based style. Code before yield performs setup. The yielded value becomes the as value. Code after yield performs cleanup. A try and finally block is normally used so cleanup still runs when the block fails.

Context managers are useful for files, locks, transactions, temporary resources, and temporary state changes. Their time and memory cost is normally small. Python creates a manager object or generator object, but it does not automatically copy the managed resource.

The code demonstrates both supported implementation styles. ResourceManager uses __enter__ for setup and returns the resource used after as. Its __exit__ method always closes the resource after __enter__ succeeds. It prints any exception information and returns False, so the original exception continues. The managed_resource function uses contextlib.contextmanager. It creates the resource before yield, yields the value used after as, and closes it in a finally block. The example catches the propagated ValueError outside the with statement so the program can continue and show that cleanup happened.

A common mistake is to say that __exit__ always runs. It runs only after __enter__ completes successfully. Another mistake is returning True without realizing that it suppresses the active exception. Developers may also assume that the value after as must be the context manager itself, but __enter__ can return another object. With contextlib.contextmanager, the generator must yield exactly once. Cleanup should normally be placed in a finally block. Catching an exception around yield and then ending normally can suppress that exception, so the code must raise it again when suppression is not intended. A context manager also does not automatically make a resource safe for concurrent use.

Start with the __enter__ and __exit__ protocol. Explain what value is assigned after as. Then name the three exception values passed to __exit__ and state that True suppresses the exception. Mention that __exit__ is not called when __enter__ fails. Finish by explaining that contextlib.contextmanager uses setup before yield and cleanup after yield.

Type hints normally do not enforce types at runtime. Python keeps annotations as metadata, usually available through __annotations__, while static type checkers use them before execution. Runtime tools can inspect and act on the metadata, but they must perform their own validation. Generic types, unions, and forward references are represented as annotation values whose exact runtime form can depend on the Python version and annotation settings.

Type hints normally do not reject a value at runtime. Python still follows dynamic typing, so a function can receive a value that does not match its annotation unless some other code checks it.

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?

Annotations are metadata associated with functions, classes, and modules. They are commonly available through __annotations__. In Python 3.14, annotations are evaluated lazily by default, so reading __annotations__ may evaluate annotation expressions and can raise an exception. In earlier versions, annotations were usually evaluated when the definition ran unless postponed annotation behavior was enabled.

Static type checkers read type hints without changing normal program execution. Editors also use them for completion and warnings. Runtime tools can use typing.get_type_hints to resolve annotations, including many forward references. Resolution may execute annotation code, allocate a result dictionary, and fail when a required name is missing.

A generic such as list[str] is represented as a generic alias. A union such as int | str is represented as a union type. A forward reference may remain a string or another delayed form until resolved.

Type hints improve clarity and tooling, but they do not replace validation of API requests, files, database values, or other external input.

The example defines a User class and a function with three annotation forms. list[User] is a generic alias. int | None is a union. The return annotation is str. The first call shows normal use. The second call proves that Python does not automatically enforce the limit annotation. The function completes because its own runtime logic accepts the supplied string value. The example then reads __annotations__ and uses get_type_hints to obtain resolved type information. The exact printed representation can vary between supported Python versions, but the runtime behavior and conclusion remain the same.

A common mistake is assuming that Python automatically rejects arguments that do not match annotations. Another mistake is treating __annotations__ as validated data rather than metadata. Developers may also assume annotations always have the same runtime representation in every Python version. Lazy evaluation, postponed annotation behavior, and forward references can change what is stored or when it is evaluated. Another mistake is calling get_type_hints on untrusted annotations without considering that annotation evaluation can execute code. Repeatedly resolving the same annotations in a busy request path can also add avoidable processing and allocation.

Begin with the conclusion that type hints do not normally enforce types. Then explain static checking, __annotations__, and runtime inspection with get_type_hints. Mention that Python 3.14 evaluates annotations lazily by default. Finish by explaining how a generic, a union, and a forward reference appear at runtime.

A dataclass inspects the annotated fields in a class and can generate methods such as __init__, __repr__, and __eq__. This removes repeated class code while keeping the fields clear. I use default_factory for mutable defaults, __post_init__ for validation or derived values, frozen to block normal field assignment, order for field based comparisons, and slots when many small objects need lower memory use.

The practical benefit of @dataclass is that it generates common class behavior from annotated fields. By default, it creates __init__, __repr__, and __eq__. The generated __init__ accepts field values and stores them on the object. The generated __repr__ shows the class name and fields. The generated __eq__ compares objects of the same class using fields marked for comparison.

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 normal default is reused as the declared default value. Mutable defaults such as lists must use default_factory. The factory runs for each new object, so objects do not accidentally share one list.

The frozen option blocks normal assignment and deletion of fields after initialization. It does not make mutable values inside the object immutable. The order option generates comparison methods from fields in declaration order and requires equality support. The slots option creates slotted instances without the usual instance dictionary, which can reduce memory use and prevents undeclared attributes.

After the generated __init__ finishes, __post_init__ runs. It is useful for validation and derived fields. In a frozen dataclass, object.__setattr__ is needed to set a derived field during this step. Dataclasses work best for clear data models. A regular class is often better when construction rules or behavior are highly complex.

The example defines an ordered, frozen, and slotted Product dataclass. The name and price fields become parameters in the generated __init__. The tags field uses default_factory, so each Product receives a separate list. It is excluded from equality, ordering, and hashing because compare is false and hash follows that setting by default. The display_name field has init set to false, so callers cannot pass it to the constructor. After initialization, __post_init__ validates the price and calculates display_name. Because the object is frozen, object.__setattr__ is used during post initialization. The generated __repr__ displays the fields, __eq__ compares the selected fields, and the generated ordering methods compare name first and price second.

A common mistake is using a list or dictionary as a direct default instead of using default_factory. Another mistake is assuming frozen makes every nested value immutable. A frozen dataclass can still contain a list whose contents can change. Developers may enable order without checking whether field declaration order matches the required comparison rule. Other mistakes include placing a required field after a field with a default, expecting __post_init__ to replace all complex construction logic, forgetting that equality requires the same class, and assuming slots supports undeclared instance attributes.

Start by saying that @dataclass generates standard methods from annotated fields. Then explain default_factory for safe mutable defaults. Finish by stating how frozen, order, slots, and __post_init__ change the generated behavior.

The GIL is a lock in the normal CPython runtime. It allows only one thread at a time to execute Python bytecode in one process. Because of this, adding threads usually does not speed up CPU heavy Python code. Threads can still help with network, file, and database work because the runtime releases the GIL while a thread waits for many blocking operations. I use multiprocessing for heavy CPU work and asyncio for many cooperative input and output tasks. Python also has an optional free threaded build, but library support must be checked.

The practical point is that Python threads are useful for waiting work, but they usually do not make CPU heavy Python code run in parallel on the normal CPython build.

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 Global Interpreter Lock, usually called the GIL, is a runtime lock in CPython. A thread must hold this lock before it can execute Python bytecode or safely work with Python objects. This design protects important interpreter state, including memory management details such as reference counts.

A process can contain many threads. The operating system may schedule those threads at the same time. However, in the normal CPython build, only one thread in that process can execute Python bytecode at a given moment. CPython switches the GIL between threads, so the program can still make progress concurrently. This is concurrency, but it is not full parallel execution of Python bytecode.

For CPU heavy work, threads often give little speed improvement. Examples include large pure Python loops, image calculations written in Python, or number processing that keeps the interpreter busy. The threads compete for the same GIL. Thread switching also adds overhead. For this work, separate processes are often better because each process has its own Python interpreter and its own GIL. ProcessPoolExecutor and multiprocessing are common choices.

Threads are still useful for input and output work. CPython releases the GIL around many blocking operations. Examples include waiting for a network response, reading a file, or waiting for a database call. While one thread waits, another thread can run. This makes thread pools useful for existing blocking libraries and for applications that need moderate input and output concurrency.

Asyncio is often better when one application must manage many network connections. It uses an event loop and cooperative tasks. A task gives control back when it reaches await. This can support many connections with fewer operating system threads. The downside is that the libraries must support async operations, and blocking code must not run directly on the event loop.

Some native libraries release the GIL while performing heavy work outside Python. For example, selected operations in scientific or compression libraries may execute native code without holding the GIL. In that case, threads may use more than one CPU core. This depends on the exact library and operation, so it should be measured rather than assumed.

Python now also supports an optional free threaded CPython build. It can run Python threads in parallel without the GIL. It is supported but is not the normal default build. Some extension modules may not support it and can cause the GIL to become enabled again. Shared mutable data still needs locks or another synchronization method. Removing the GIL does not remove race conditions.

My production choice is based on the workload. I use threads for blocking input and output with synchronous libraries. I use asyncio for many cooperative input and output tasks. I use processes for CPU heavy Python work. I consider the free threaded build only after checking package support, thread safety, and measured performance.

First, identify whether the workload spends most of its time computing or waiting. Second, check whether the code runs mainly as Python bytecode or inside a native library that releases the GIL. Third, choose threads for blocking input and output when synchronous libraries are already used. Choose asyncio when many tasks can cooperate through await. Choose multiprocessing or ProcessPoolExecutor for heavy Python computation. Fourth, protect shared mutable data because the GIL does not make a complete operation automatically safe. Finally, measure the real workload. Confirm throughput, latency, CPU use, memory use, and process overhead before deciding that one concurrency model is better.

This example runs the same CPU task with a process pool and several waiting tasks with a thread pool. The CPU function performs pure Python arithmetic, so separate processes allow work to use different interpreter processes. The input and output example uses sleep to represent waiting for a network, file, or database operation. Threads help there because one thread can run while another waits. The example does not claim that sleep is real production input and output. It only demonstrates the scheduling difference. The main function protects process creation and allows the example to run correctly on platforms that start new processes by importing the module.

A common mistake is saying that the GIL makes Python completely single threaded. Python can run many threads, but the normal CPython build allows only one thread at a time to execute Python bytecode in one process. Another mistake is saying that the GIL makes shared data safe. Several bytecode steps can still interleave, so locks may be required. Candidates also assume that threads never help CPU work. Native code may release the GIL, so the result depends on the library. Another mistake is using asyncio for blocking code without moving that work away from the event loop. Finally, do not claim that every Python installation is free threaded. The free threaded build is optional.

Start by saying that the answer applies to the normal CPython build. Then separate CPU heavy work from input and output work. Explain threads, asyncio, and processes as workload choices. Mention the optional free threaded build near the end. Also state that the GIL does not replace application locks. This shows both current runtime knowledge and practical engineering judgment.

Descriptors are objects stored on a class that can control how an attribute is read, assigned, or deleted. They use __get__, __set__, and __delete__. A descriptor that defines __set__ or __delete__ is a data descriptor. A descriptor that defines only __get__ is a non data descriptor. Property is a data descriptor because the property type provides __get__, __set__, and __delete__. Its methods call the getter, setter, or deleter supplied by the class, and raise AttributeError when the required function is missing. Python functions also act as non data descriptors, which is how an instance method becomes bound to an instance.

The practical purpose of a descriptor is to control attribute access while callers continue to use normal dot syntax. A descriptor is an object stored on a class. Python may call its __get__ method when an attribute is read, __set__ when it is assigned, and __delete__ when it is deleted.

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 data descriptor defines __set__ or __delete__. It takes priority over a value with the same name in the instance dictionary. A non data descriptor defines __get__ without defining __set__ or __delete__. An instance value can normally override it.

Property uses this protocol. A property object is stored on the class. Its __get__ calls the getter. Its __set__ calls the setter. Its __delete__ calls the deleter. The property type still has these descriptor methods when a setter or deleter was not supplied, so the missing operation raises AttributeError.

Functions stored on a class are non data descriptors. Their __get__ creates bound methods that automatically pass the instance as the first argument.

Descriptor access is normally constant time for dictionary backed storage, but it adds lookup and function call work. The descriptor object is shared by the class, while each instance usually stores its own managed value.

The example uses one custom data descriptor and one property. PositiveNumber is stored on the Product class. __set_name__ records a private storage name when the class is created. __get__ returns the descriptor during class access and returns the saved instance value during instance access. __set__ validates each new value before storing it in the instance dictionary. The label property validates one specific attribute. Reading label calls its getter, while assigning label calls its setter. The describe function also demonstrates descriptor behavior because Python turns it into a bound method when it is accessed through a Product instance.

A common mistake is saying that every descriptor must define all three protocol methods. A descriptor may define only __get__. Another mistake is calling every descriptor with __get__ a data descriptor. The defining rule is whether its type provides __set__ or __delete__. Candidates may also say that a read only property is a non data descriptor. It is still a data descriptor because the property type provides __set__ and __delete__, even when those operations raise AttributeError. Another mistake is reading or assigning the public property name inside its own getter or setter, which causes endless recursion. Developers may also forget to return the descriptor itself when __get__ receives instance as None. Finally, storing instance values directly on a shared descriptor can accidentally share state across every instance.

Start with the practical result: descriptors control attribute access behind normal dot syntax. Then name __get__, __set__, and __delete__. Explain the lookup difference between data and non data descriptors. Finish by connecting property to data descriptors and bound methods to function descriptors.