Object-Oriented Programming practice questions

self.work()

Why it fails: self.work() performs a normal attribute lookup on the self instance, which means the method resolution starts from the class of self — in this scenario, Manager. Since Manager.work() is the method currently executing, calling self.work() inside that method will simply dispatch to the same overridden method again, creating an infinite recursive loop. This is not a delegation to the parent at all; it is a dynamic dispatch that honors the subclass override, so it can never reach Employee.work().

Python always calls the method from the last base class

Why it fails: Python does not use a simplistic 'last base class wins' rule; it uses C3 linearization, which produces a monotonic method resolution order that preserves both local precedence order and constraints from the entire inheritance graph. For example, in class C(A, B), if both A and B define foo, C.foo resolves to A.foo because A is listed first, not last. The actual MRO can intermix classes in a sequence that is neither purely first-to-last nor last-to-first, especially in diamond hierarchies, making this option incorrect.

The 'foo' method in class B is defined after class A's 'foo' in the same file

Why it fails: The physical order of method definitions in a source file has no effect on method resolution; Python compiles the entire module before execution and builds the MRO at class creation time solely from the base-class tuple in the class statement. Even if B.foo appears textually after A.foo, it is the inheritance order — not the order of def blocks — that determines which attribute is found first during attribute lookup. File-level ordering is irrelevant to C3 linearization and attribute resolution.

Python uses depth-first, left-to-right resolution

Why it fails: Python's MRO is not depth-first left-to-right; that was the behavior in older Python 2 versions and was replaced by C3 linearization starting in Python 2.3. C3 fixes the inconsistency and duplicate-lookup problems of depth-first traversal in diamond inheritance (e.g., class D(B, C) with a common base A). It ensures a monotonic order where a subclass always appears before its superclasses and every class appears exactly once, which a naive depth-first approach cannot guarantee.

class MyClass: attr: int = 0

Why it fails: This is a type annotation, not a class attribute assignment (though it may be interpreted as such in some contexts, it is not a standard way).

class MyClass: def set_attr(self): MyClass.attr = 0

Why it fails: This defines a method that sets a class attribute, but the attribute is not defined at class creation.

class MyClass: def __init__(self): self.attr = 0

Why it fails: This creates an instance attribute, not a class attribute.

Define a new __init__ in Dog that does not call super

Why it fails: Defining __init__ in Dog without calling super().__init__() means Python will treat Dog's __init__ as a complete override of the inherited one. As a result, the Animal constructor's body never executes, so self.name is never assigned; any attempt to read dog.name will raise AttributeError (or the attribute will be missing). This breaks the implicit contract that a subclass initializer must cooperate with its parent, even if Dog adds its own parameters.

Dog will automatically inherit the __init__ method

Why it fails: Merely relying on automatic inheritance is not enough: Dog will indeed inherit Animal.__init__ through normal attribute lookup, but that inherited method still expects a name argument exactly as Animal required. If client code tries to instantiate Dog() without passing name, Python raises TypeError: __init__() missing 1 required positional argument: 'name'. Additionally, "automatic inheritance" does nothing to let a Dog-specific __init__ coexist with the parent's; you'd be locked to the parent's initialization logic and cannot add Dog-only fields.

Use a decorator to initialize

Why it fails: There is no built-in or idiomatic decorator whose purpose is to initialize or chain __init__ methods. Decorators like @classmethod, @staticmethod, or @property are intended for other behavior, and using a custom class decorator that wraps __init__ would be a nonstandard, obscure workaround at best. A decorator cannot by itself solve the constructor-chaining problem cleanly, because the correct solution is to explicitly call super().__init__ from within Dog.__init__.

Define __init__ that raises NotImplementedError

Why it fails: Raising NotImplementedError inside __init__ is a reliable way to make a class non-instantiable. Every successful call to the class constructor implicitly invokes __init__, so throwing an exception at that point halts instance creation. Subclasses must override __init__ (typically to define their own state) before they can be instantiated. This pattern is concise and works in all Python versions.

Use a naming convention like _BaseClass

Why it fails: A naming convention such as _BaseClass is purely advisory; it communicates intent to human readers but has no runtime effect. Python does not enforce the leading underscore rule, so code can still call _BaseClass() and receive an instance. Tools like linters may warn, but they do not block creation. Thus it is not a mechanism for preventing instantiation.

Define __new__ to return None

Why it fails: Overriding __new__ to return None technically makes the class call return None, but this does not prevent the constructor from running; rather, it subverts Python's object-creation protocol. When __new__ returns None, Python skips __init__ and silently delivers a None object, forcing the caller to handle a missing instance, which often leads to AttributeError. Returning None does not raise a clear error and breaks the expected contract that a constructed object is an instance of the class, making it an unreliable and confusing approach.

obj.attr = 5 on an instance

Why it fails: Assignment to obj.attr = 5 targets an existing instance object, not the class object. Python writes this binding into that instance's __dict__, so only that one object sees attr unless another instance has its own assignment. The class remains untouched, which means this operation can neither define a new class attribute nor serve as a valid way to define a class.

class MyClass: def method(self): pass

Why it fails: The class body 'class MyClass: def method(self): pass' does produce a class, but the assignment it makes binds a function object to the name method in the class namespace. That function is accessed as an instance method through the descriptor protocol, and it is a behavior rather than a data attribute. Because the question asks for a class-attribute definition, this method-defining class body is not a valid answer.

class MyClass: def __init__(self): self.attr = 5

Why it fails: Although this is a valid class definition, the line 'self.attr = 5' executes only when __init__() is invoked on a new instance. It writes attr into the instance's own __dict__, not into the class's namespace, so the class object has no attr attribute. Every instance gets a separate copy, making this an instance-attribute assignment rather than a class-attribute definition.

2 0 0

Why it fails: Choosing 2, 0, 0 implies you think `Sample.count` is correctly incremented to 2, but each instance somehow has its own `count` attribute initialized to 0. In the exhibit no `self.count = ...` assignment exists inside `__init__`, so instance attribute lookup finds no key in the instance `__dict__` and falls back to the class attribute. Therefore `a.count` and `b.count` also evaluate to 2, not 0.

2 1 1

Why it fails: `2, 1, 1` would require each instance to store its own private counter value of 1, masking the class attribute during instance access. However, the code never creates an instance attribute named `count`, so `a.count` and `b.count` do not perform an instance-level lookup that finds a different value; they traverse up to `Sample.count`. The class attribute is shared and unchanged by instance access, so the second and third lines mirror the class value of 2, not a per-instance 1.

0 2 2

Why it fails: This output mistakenly places the first `print(Sample.count)` before the two constructor calls, or assumes incrementing happens after printing. In the actual sequence, both `Sample()` calls run first and each increments the class variable, so the printed class attribute is already 2. The subsequent instance accesses also resolve to that same class attribute, so the first line is 2 and the following lines are also 2, not 0 and then 2.

Create subpackage directories with their own __init__.py, then create main package directory with __init__.py, then place module files, then import using dot notation.

Why it fails: This order is invalid because Python package resolution requires the parent package directory to exist before its subpackages. A subpackage is an attribute of its parent, and without the parent's __init__.py on disk, the import system cannot bind the child to any namespace. In practice, you must establish the top-level package directory first, then nest the subpackage directories.

Create main package directory with __init__.py, then place module files, then create subpackage directories with their own __init__.py, then import using dot notation.

Why it fails: Placing module files before creating subpackage directories prematurely commits modules to the parent namespace, which defeats the purpose of a subpackage layout. If modules are meant for a subpackage, they must be physically located inside that subpackage directory; otherwise, relative imports and dotted paths will fail at runtime. The correct workflow is to define the full directory tree first, then add the module files.

Import using dot notation, then create main package directory with __init__.py, then create subpackage directories with their own __init__.py, then place module files.

Why it fails: An import statement is executed at runtime and requires the target package to already exist and be importable via sys.path; attempting to import before creating the package structure is impossible because the import machinery will raise ModuleNotFoundError. Furthermore, using dot notation implies the parent package has already been initialized and its __init__.py executed, which cannot happen before the directories exist. Importing is the final verification step, not a setup step.

A descriptor can be used to create properties with custom behavior

Why it fails: That is correct.

Class variables assigned to a descriptor are automatically intercepted

Why it fails: Correct: descriptor protocol is triggered on instance attribute access.

A descriptor must implement __get__

Why it fails: At least __get__ is needed for a non-data descriptor.

Private attributes (with __) are inherited unchanged.

Why it fails: Name mangling renames them, so they are not directly inherited.

Python supports method overloading based on parameters.

Why it fails: Python does not support method overloading; methods override.

Error: 'MyClass' object has no attribute 'value'

Why it fails: This AttributeError would occur only if the value attribute had never been assigned before it was accessed. In this program, __init__ runs at construction time and carries out self.value = 10 unconditionally, so the attribute exists on every MyClass instance from the moment it is created, making this error impossible to raise.

<__main__.MyClass object at 0x...>

Why it fails: The string '<__main__.MyClass object at 0x...>' is the default repr of a class instance, which is used when an object itself is handed to print() and no __str__ method overrides it. Because the exhibit prints obj.value—an attribute, not the object reference—Python never calls repr(obj); it prints the integer 10, so this representation is irrelevant to the output.

None

Why it fails: None would be the output only if the argument given to print() evaluated to None, as when calling a function with no return statement. Here the argument is obj.value, which was initialized to 10, so the output is the string representation of that integer—not None; the fact that print() itself returns None is irrelevant because its return value is not printed.

The descriptor's `__get__` is called only if `__getattr__` is not defined.

Why it fails: Descriptors are independent of __getattr__.

If the attribute exists in the instance's __dict__, the descriptor is ignored.

Why it fails: Instance attribute always takes precedence.

The descriptor must be defined in the class's metaclass.

Why it fails: No, it's defined as a class variable.

Default x

Why it fails: The label 'Default x' might suggest Python supplies a built-in value for x, but no class-level default exists here. The assignment a.x = 'hello' triggers the overridden __setattr__, which converts the string to uppercase before storing it in the instance __dict__. Furthermore, __getattr__ is never invoked because 'x' is found normally in __dict__, so the output cannot be a default. Therefore 'Default x' is incorrect.

hello

Why it fails: Choosing 'hello' assumes the assignment stores the value verbatim, but that is exactly what the override prevents. The code passes value.upper() to the parent implementation, so the lowercase string never enters the instance dictionary. Accessing a.x returns the transformed 'HELLO' instead of the original 'hello', making this option incorrect.

AttributeError

Why it fails: An AttributeError would occur only if attribute access failed, for example if __getattr__ raised it or if the attribute was never stored. Here the overridden __setattr__ correctly calls super(), which creates the attribute in the instance namespace. Since 'x' is successfully set to 'HELLO', print(a.x) finds it without error, so this option is wrong.

0

Why it fails: An output of 0 would require the setter to explicitly reset `_radius` to 0, but no such fallback exists in the property definition. The initial value of `_radius` is 5, and the rejected assignment does not change it. Nothing in the shown code assigns 0, so this answer is incorrect.

-3

Why it fails: The setter's condition prevents any negative number from being stored in `_radius`, so the attempted value -3 is never assigned to the underlying attribute. Consequently, `_radius` retains its prior value of 5, not -3. This is the direct result of the guard clause inside the setter.

AttributeError

Why it fails: `AttributeError` would occur only if no setter were defined and you tried to assign to a read-only property. Here, `@radius.setter` explicitly defines a setter, so the assignment `-3` is valid Python; it simply invokes the setter method. Since the setter ignores negative values, no exception is raised.

__len__ and __contains__

Why it fails: __contains__ is for membership, not slicing.

__iter__ and __next__

Why it fails: These support iteration, not slicing directly.

__getitem__ alone

Why it fails: While __getitem__ is essential, sequences are expected to have __len__ as well.

__getitem__ and __setitem__

Why it fails: __setitem__ is for item assignment, not necessary for read-only sequences.

Private attributes (with double underscore) of the base class are accessible in the subclass.

Why it fails: This is false. Private attributes (double underscore prefix) undergo name mangling to _ClassName__attribute, so they are not directly accessible in subclasses.

The super() function returns a proxy object for method delegation.

Why it fails: This is false. The super() function returns a proxy object that delegates method calls along the MRO, not a direct parent class instance.

__getitem__

Why it fails: __getitem__ is required because it supports both subscription access (obj[i]) and, via the sequence iteration protocol, repeated calls with increasing indices until IndexError. It also enables membership testing because the in operator can sequentially query __getitem__ when no __contains__ exists. Therefore, along with __init__ and __iter__, __getitem__ is one of the three methods that must be implemented for an immutable, iterable object.

__len__

Why it fails: __len__ participates in the container protocol but is not a prerequisite for iteration or membership. You can iterate by letting __getitem__ raise IndexError at the end, or by implementing __iter__, and the in operator can rely on linear scanning without ever calling len. For these reasons __len__ is useful for exposing size, but it is optional and not one of the three required methods.

__contains__

Why it fails: Membership testing with the in operator does not depend on __contains__; Python automatically falls back to iterating through the object via __iter__ or __getitem__ when a dedicated __contains__ is absent. Adding __contains__ is a performance optimization that avoids scanning every element, but it is not one of the methods needed to build an immutable iterable, so its absence does not break the protocol.

MyClass has a class attribute called display.

Why it fails: display is defined with the def keyword and takes self as its initial parameter, so it is a method, not a class attribute. Although the function object does reside in the class namespace, it is not a data attribute shared like a variable; accessing it through an instance invokes the descriptor protocol and yields a bound method. Therefore, calling display a 'class attribute' mischaracterizes its role as instance-specific behavior.

MyClass has both __init__ and display as class methods.

Why it fails: Both __init__ and display lack the @classmethod decorator and take self—not cls—as their first parameter. A class method is created with @classmethod and is bound to the class itself, whereas these are ordinary instance methods that are bound to the instance on which they are called. In particular, __init__ is the instance initializer executed after instance creation, not a class-level operation.

The `@override` decorator is required.

Why it fails: Python has no built-in `@override` decorator; it is not required for overriding.

The subclass method can have a different number of parameters.

Why it fails: For proper overriding, the signature should match; otherwise, it's not considered overriding (though Python does not enforce it).

d = Dog(); d.bark()

Why it fails: Calling `Dog()` without a `name` argument fails immediately because Python automatically invokes `Dog.__init__` on any instantiation. Since `__init__` is defined as `def __init__(self, name)`, the missing positional argument causes a `TypeError: __init__() missing 1 required positional argument: 'name'`, so the instance is never created and `bark()` is never reached.

Dog.bark()

Why it fails: Accessing the method via the class, `Dog.bark`, retrieves a plain function object, not a bound method. The call `Dog.bark()` therefore supplies no `self` argument, and Python raises `TypeError: Dog.bark() missing 1 required positional argument: 'self'`. You must call the method on an instance (e.g., `dog.bark()`) so that the instance is automatically passed as `self`.

d = Dog; d.bark()

Why it fails: The statement `d = Dog` does not create an instance; it merely binds the class object itself to the name `d`. Consequently, `d.bark()` is identical to `Dog.bark()`—it attempts to call the unbound function with no `self`, causing a `TypeError` for the missing required positional argument. To get an instance, you must call the class with parentheses, e.g., `Dog("Rex")`.