Advanced Object Oriented Programming practice questions

Non-data descriptors can override instance dictionary lookup.

Why it fails: Non-data descriptors implement only __get__, so instance __dict__ entries take precedence over them during attribute lookup. It is tempting because non-data descriptors do participate in lookup, but data descriptors define __set__ or __delete__ and therefore override instance dictionary entries, which is the actual distinction.

Data descriptors only function with class attributes.

Why it fails: Data descriptors are defined by implementing __set__ or __delete__ alongside __get__, so they take precedence over instance dictionaries; the class-attribute placement is irrelevant since both descriptor types normally live on the class. It tempts because descriptors are usually declared as class attributes, but that describes implementation location, not the data versus non-data distinction.

Non-data descriptors are always read-only.

Why it fails: Non-data descriptors implement only __get__, yet they remain writable because instance __dict__ entries shadow them, so read-only behaviour is not guaranteed. It tempts because __get__-only descriptors often expose computed values, but the actual axis is presence of __set__ or __delete__, which data descriptors add to override instance attributes.

The __new__ method cannot accept variable arguments in Python 3.

Why it fails: __new__ accepts *args and **kwargs in Python 3, so variable arguments are not the limitation. Overriding __new__ alone still runs __init__ on every call, breaking singleton semantics. It is tempting because __new__ does construct instances, but metaclass __call__ is needed to intercept instantiation itself.

The __new__ method is reserved for static methods only.

Why it fails: __new__ is a static method implicitly, not reserved for static methods only; it is a normal overridable constructor hook. The actual problem is that __init__ still executes on each instantiation. It is tempting because __new__ behaves statically, but that does not prevent its use in Singleton implementations.

It is required for thread-safe access to the instance variable.

Why it fails: Thread safety requires explicit locking around instance creation; neither __new__ nor metaclass __call__ provides it automatically. The genuine reason to prefer metaclass __call__ or a decorator is controlling __init__ re-execution. It is tempting because __new__ governs creation, but concurrency needs separate synchronisation.

Use the __call__ method to raise a TypeError if the base class is instantiated.

Why it fails: This would prevent instantiation, not registration during definition.

Set the __new__ method of the metaclass to return None if the name is 'Base'.

Why it fails: Returning None from __new__ would prevent the class from being created at all, causing an error.

Define a decorator on the base class that removes it from the metaclass registry.

Why it fails: Decorators run before metaclass logic, making this approach complex and prone to race conditions.

It triggers a SyntaxError.

Why it fails: A class decorator simply rebinds the name to whatever the callable returns, so returning a modified class is legal and raises no SyntaxError. It tempts because decorator syntax looks like special grammar, but the actual mechanism is ordinary callable application, with syntax errors arising only from malformed decorator expressions themselves.

The class cannot be instantiated.

Why it fails: The returned object replaces the original name and remains fully instantiable provided it is itself a class or callable producing instances. It tempts because a decorator returning something unexpected can break instantiation, but that depends on what the decorator returns, not on decoration itself, which imposes no such restriction.

The metaclass is ignored.

Why it fails: Class decoration rebinds the name after class creation, so the metaclass has already built the class and is unaffected. It tempts because decorators and metaclasses both intercept class creation, but they operate at different stages: metaclasses run during class body execution, decorators afterwards on the finished object.

They are strictly for private attribute management.

Why it fails: They have a much wider scope.

They only apply to the class itself, not its subclasses.

Why it fails: Metaclasses are inherited.

Non-data descriptors can define __set__.

Why it fails: That would make them data descriptors.

They only work for instance attributes.

Why it fails: They work for both.

Name mangling transforms `__balance` to `__SavingsAccount_balance` in the subclass context.

Why it fails: Name mangling is based on the class where the identifier textually appears. In the subclass, `__balance` would be mangled to `_SavingsAccount__balance`, but that attribute does not exist unless defined there. The base class attribute remains `_BankAccount__balance`, so this does not explain access.

The subclass must define its own `__balance` attribute to avoid the error.

Why it fails: Defining a new `__balance` in the subclass would create a separate attribute with its own mangled name, not access the base class's balance. This would not resolve the error and would lead to two distinct attributes, causing confusion and potential bugs.

The attribute is truly private and cannot be accessed from any other class, so the subclass must use a public getter.

Why it fails: Python does not enforce true privacy; name mangling is a convention to avoid accidental name clashes. The attribute can be accessed using its mangled name from outside the class, so the statement that it cannot be accessed is incorrect. A public getter is good practice but not the only way.

Use a single `__add__` that always converts `other` to a `Vector` by broadcasting its value.

Why it fails: Broadcasting a scalar to a vector may work for numbers, but it would also attempt to convert non-numeric types, leading to errors. It also does not handle the case where `other` is a `Vector` correctly if the conversion is not type-aware. This approach is too broad and can cause incorrect behavior for unsupported types.

Implement `__add__` only for `Vector` and rely on `__radd__` to handle scalar addition when the scalar is on the left.

Why it fails: `__radd__` is invoked when the left operand does not implement `__add__` or returns `NotImplemented`. For `v1 + 5`, the left operand is a `Vector`, so `__add__` is called first. If it only handles `Vector`, it may return `NotImplemented`, then `__radd__` on the `Vector` would be called, but that would not correctly handle the scalar on the right. This strategy does not directly solve the requirement.

In `__add__`, attempt to iterate over `other`; if iteration fails, treat `other` as a scalar.

Why it fails: Using iteration to distinguish types is unreliable and can lead to unexpected behavior. For example, a string is iterable but should not be treated as a vector or scalar. This approach can mask errors and is not explicit, making the code harder to maintain and debug.

Descriptors are only invoked for attributes accessed on instances, not on the class itself.

Why it fails: Descriptors are invoked for attribute access on both instances and classes, though the behavior differs. When accessed on the class, __get__ receives None as the instance argument. This statement is incorrect because it falsely claims descriptors are not invoked on the class. In the validation scenario, accessing the descriptor via the class could return the descriptor object itself or a computed value, depending on the implementation.

If the descriptor defines __get__ but not __set__, it is a non-data descriptor, and instance attributes with the same name will override it.

Why it fails: While it is true that a descriptor with only __get__ is a non-data descriptor, and instance attributes can override it, this statement is not directly relevant to the validation scenario. The question asks about correct statements regarding descriptors for validation, and a validation descriptor typically needs __set__ to enforce constraints on assignment. This statement is technically accurate about descriptors in general but does not describe the required behavior for validation.

The descriptor's __set_name__ method is automatically called during class creation to inform the descriptor of the attribute name it is assigned to.

Why it fails: While __set_name__ is called during class creation and can be useful for descriptors that need to know their attribute name, it is not directly related to the validation logic itself. The question focuses on how descriptors work for validation, and __set_name__ is an auxiliary feature. It is a correct statement about descriptors in general, but it is not one of the two most relevant correct statements about descriptor behavior for validation.

`__init_subclass__` is called on the subclass after its class body is executed, so it can access class attributes defined in the subclass.

Why it fails: `__init_subclass__` is called on the parent class, not the subclass, and it is invoked after the subclass's class body has been executed. However, it is a class method of the parent, so `cls` refers to the parent, not the new subclass. The new subclass is passed as an argument. It can access the subclass's attributes via that argument, but the statement incorrectly says it is called on the subclass.

`__init_subclass__` is only called for direct subclasses, not for subclasses of subclasses.

Why it fails: `__init_subclass__` is called for every subclass in the inheritance chain, including indirect subclasses. When a subclass of a subclass is defined, the method is called on its immediate parent, which may itself be a subclass. If the parent does not override `__init_subclass__`, the call propagates up the MRO. So it works for all descendants, not just direct subclasses.

`__init_subclass__` must be defined as a static method to work correctly.

Why it fails: `__init_subclass__` is implicitly converted to a class method. Defining it as a static method would remove the automatic `cls` argument and break the expected behavior. It should be defined as a regular instance method in the class body; Python automatically treats it as a class method. Using `@staticmethod` would prevent access to the parent class and is incorrect.

class Child(Base1, Base2): def greet(self): Base1.greet(self) super().greet()

Why it fails: This hybrid approach calls Base1.greet() explicitly and then super().greet(), which will call the next method after Child in the MRO, potentially Base1.greet() again or Base2.greet(), leading to duplicate or skipped calls. It does not reliably call both parent methods exactly once in order. It also breaks the cooperative super() chain if Base1.greet() does not call super().

class Child(Base1, Base2): def greet(self): super(Base1, self).greet() super(Base2, self).greet()

Why it fails: Using super(Base1, self) starts the MRO search after Base1, which would call Base2.greet(), and super(Base2, self) starts after Base2, potentially calling object.greet() or raising AttributeError. This does not call both parent methods in the intended order and is incorrect for cooperative multiple inheritance. It also bypasses Base1.greet() entirely.

class Child(Base1, Base2): def greet(self): Base1.greet(self) Base2.greet(self)

Why it fails: This explicitly calls each parent method, which works for simple cases but bypasses the cooperative multiple inheritance mechanism. It does not use super(), so it will not respect the MRO and may cause issues if the inheritance hierarchy changes or if other classes in the MRO also need to be called. It also duplicates calls if Base1 and Base2 share a common ancestor.

`__init_subclass__` allows creating classes whose behavior differs at the metaclass level, such as custom `__call__` on the class itself.

Why it fails: Customizing how the class itself is called (i.e., overriding `__call__` on the metaclass) requires a metaclass because `type.__call__` is what controls instantiation. `__init_subclass__` is a method on the parent and cannot change the metaclass behavior of subclasses. The scenario asks for a lighter-weight alternative, so this capability is not relevant.

`__init_subclass__` is automatically inherited by all subclasses and can be overridden to customize behavior for each level of the hierarchy.

Why it fails: While `__init_subclass__` is inherited, it is defined as an implicit classmethod on the parent and is called for each new subclass, but it is not typically overridden by subclasses to customize their own creation. Overriding it in a subclass affects that subclass's children, not itself. The statement overstates its role as a per-level customization mechanism.

`__init_subclass__` can modify the namespace of the subclass before the class object is created.

Why it fails: `__init_subclass__` runs after the subclass object already exists, receiving the class as its first argument. It cannot alter the namespace before class creation. Pre-creation namespace modification is a job for `__prepare__` or the metaclass `__new__`, not for `__init_subclass__`.

__getattribute__, __setattr__, and __getattr__

Why it fails: This combination lacks __getitem__, so dictionary-style access via config['host'] would not work unless the class inherits from dict or implements __getitem__ elsewhere. __getattribute__ and __setattr__ are correct for dot notation and restriction, but __getattr__ is redundant if __getattribute__ is defined. The missing __getitem__ makes this option incorrect for the scenario.

__getattr__, __setattr__, and __getitem__

Why it fails: __getattr__ is only called when normal attribute lookup fails, so it is not the primary method for accessing existing attributes. __setattr__ is called for all attribute assignments, which can enforce restrictions, but __getattr__ is not the right choice for normal access. __getitem__ handles dictionary-style access. This combination would not correctly support dot notation for existing attributes without additional logic.

__getattr__, __setattr__, and __getitem__ with __slots__

Why it fails: Using __slots__ can restrict attributes, but it defines a fixed set of attributes at class creation, which may not align with dynamic prevention after initialization. __getattr__ is still not the primary method for normal access. __getitem__ is correct, but the combination with __slots__ and __getattr__ does not provide the same level of control as __getattribute__ and __setattr__.

Decorate `Circle` itself with `@abstractmethod` so that the class object becomes abstract.

Why it fails: `@abstractmethod` is designed to mark methods, not classes; applying it to a class does not add anything to `__abstractmethods__`. The `abc` machinery collects abstract methods when the class is created and rejects instantiation only if that set is non-empty. Decorating the class leaves the set empty, so `Circle` would still be instantiable.

Set the `__slots__` attribute on `Circle` to an empty tuple so that Python treats it as non-instantiable.

Why it fails: `__slots__` controls attribute storage and prevents the creation of per-instance `__dict__` entries; it has no bearing on instantiation eligibility. A class with empty slots can still be instantiated normally. Confusing memory layout controls with abstractness is a category error, and this would not stop `Circle()` from succeeding.

Define `__init__` in `Circle` that raises `NotImplementedError` unconditionally.

Why it fails: An `__init__` that always raises would also block subclasses that call `super().__init__()`, which is common and often necessary for shared setup. It does not express an abstract contract and provides no way for well-behaved subclasses to opt in. The goal is to block only direct instantiation, so an unconditional raise in `__init__` is too broad and breaks subclassing.

class Logger: _instance = None def __new__(cls, *args, **kwargs): if not hasattr(cls, '_instance'): cls._instance = super().__new__(cls) return cls._instance

Why it fails: This implementation checks `hasattr(cls, '_instance')`, but since `_instance` is defined as a class attribute, `hasattr` will always return `True` after the first instantiation, even for subclasses that inherit it. This means subclasses would incorrectly share the parent's instance, and the check is flawed because the attribute exists from the start.

class Logger: def __new__(cls, *args, **kwargs): if not hasattr(cls, '_instance'): cls._instance = super().__new__(cls) return cls._instance

Why it fails: This implementation does not define `_instance` as a class attribute initially. The first time `__new__` is called, `hasattr` returns `False`, so it creates an instance and sets `cls._instance`. However, because `_instance` is set on the class, subclasses will inherit it, leading to shared instances. Also, it lacks proper handling for multiple subclasses.

class Logger: _instance = None def __new__(cls, *args, **kwargs): if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance

Why it fails: This implementation stores the instance in `cls._instance`, which means each subclass will have its own `_instance` attribute if not inherited properly. However, if a subclass does not override `_instance`, it will share the parent's instance. To allow proper subclassing with separate singletons per subclass, you should store the instance in a dictionary keyed by class, or use `cls._instance` but ensure it is not inherited. This implementation may not work as intended for subclasses.

Call the grandparent class directly.

Why it fails: Calling the grandparent directly skips the sibling's method entirely and can execute the grandparent twice in diamond inheritance. It is tempting because explicit grandparent calls appear to guarantee initialisation, and would be correct in a non-cooperative hierarchy where no super() chain is used.

Use the __bases__ attribute to iterate through parents.

Why it fails: __bases__ lists immediate parent classes but does not resolve the MRO or advance the cooperative chain, so sibling methods are invoked out of order or repeatedly. It is tempting because __bases__ exposes parent classes, and would suit introspection or debugging rather than method dispatch.

Explicitly call the sibling class method by name.

Why it fails: Naming the sibling class directly bypasses the MRO chain that super() follows, defeating cooperative multiple inheritance and risking duplicate or skipped initialisation. It is tempting because direct calls work in simple hierarchies, and would be correct where the sibling is unrelated and no cooperative chain exists.

__format__

Why it fails: __format__ handles format-spec string conversion via format() and f-strings, not the informal str() output; __str__ provides that. It tempts because __format__ does produce user-facing text, which is correct when custom format specifications must be honoured.

__unicode__

Why it fails: Python 3 removed __unicode__; it existed only in Python 2, where it returned a unicode string. It is tempting because Python 2's str/unicode split mirrors __str__/__repr__, but under Python 3 __str__ alone supplies the informal, user-facing representation.

__repr__

Why it fails: __repr__ returns the official, unambiguous representation intended for developers and debugging, ideally evaluable to recreate the object. It is tempting because it also produces a string, but the informal user-facing output the question asks for is __str__'s role.

The metaclass must manually convert it back to a static method.

Why it fails: The decorator applies at class-body execution, before the metaclass receives the namespace, so the descriptor is already a staticmethod object; no manual reconversion is needed. It tempts because metaclasses can rewrite attributes in __new__, and custom wrapping of descriptors is a real technique in advanced metaprogramming.

It raises a TypeError at class definition time.

Why it fails: Applying @staticmethod alongside a metaclass is entirely legal; the decorator simply wraps the function in a staticmethod descriptor stored in the class namespace, and type creation proceeds normally. It tempts because metaclass conflicts with other class-level constructs do raise TypeError, so learners generalise that error to decorators.

The metaclass will treat the method as an instance method.

Why it fails: The staticmethod descriptor is stored unchanged in the namespace the metaclass receives, so attribute lookup still returns the plain function without binding self. It tempts because metaclasses can transform methods, and a custom __new__ that unwraps descriptors would indeed produce instance-method behaviour.

It causes circular dependency issues.

Why it fails: Strong references keep observers alive after their owners discard them, so they are never garbage-collected and leak; the fix is weak references. Circular dependency is the concern when two objects reference each other directly, which is a structural design issue rather than a lifetime one.

It makes the notify method thread-unsafe.

Why it fails: Reference strength governs object lifetime, not concurrency; notify remains thread-unsafe regardless because the observer list needs locking during iteration. Thread safety would be the goal when multiple threads mutate or traverse the list concurrently, addressed with synchronisation rather than weak references.

It violates the principle of encapsulation.

Why it fails: Encapsulation concerns exposing internal state through public interfaces; holding strong references does not breach it, since the list stays private. Encapsulation would be the aim when designing accessor methods or hiding implementation details, which is unrelated to garbage collection of observers.

The class will be created, but calling the missing method will raise an AttributeError.

Why it fails: Instantiation itself fails with TypeError before any method call, so AttributeError never arises. It is tempting because AttributeError is the usual error when calling a method that genuinely does not exist on an object, which is what a missing implementation superficially resembles.

The missing method will default to a 'pass' statement.

Why it fails: Python raises TypeError at instantiation when abstract methods remain unimplemented; it never substitutes a pass body. It is tempting because ordinary inherited methods can be overridden with pass, and abstract methods are sometimes assumed to behave as optional stubs rather than enforced contracts.

The parent ABC will automatically provide a NotImplementedError.

Why it fails: Instantiating such a subclass raises TypeError at object creation, because ABCMeta blocks instantiation while abstract methods remain unimplemented; the ABC itself supplies no fallback body. It is tempting because abstract methods often contain a raise NotImplementedError stub, but that stub only runs if a subclass explicitly calls the parent method via super().