Select Two (Multi-Select) Questions

Private attributes (with __) are inherited unchanged.

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

Python supports method overloading based on parameters.

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

The site-packages directory is searched before the PYTHONPATH directories.

Why wrong: PYTHONPATH entries are inserted before site-packages.

The current working directory is always the last entry in sys.path.

Why wrong: The current working directory is not automatically added; the script directory is.

The current working directory is always the first element in `sys.path`.

Why wrong: This is false because the first element of `sys.path` depends on how Python was started. When running a script, `sys.path[0]` is the script's directory, not necessarily the current working directory—the process's CWD could be different if the script was invoked with a path from elsewhere. Only in interactive mode or when executing `-c` does the empty string (representing the CWD) appear first, so saying "always" is incorrect.

`sys.path` is initialized from the PYTHONPATH environment variable.

Why wrong: This is false because `sys.path` is not built exclusively from the `PYTHONPATH` variable. At interpreter startup, Python constructs `sys.path` by combining (in order) the script's directory or the current working directory for interactive mode, the directories listed in `PYTHONPATH`, and installation-dependent default paths such as the standard library and `site-packages`. So `PYTHONPATH` is merely one contributing source, not the initializer of the entire list.

`sys.path` is a tuple of strings.

Why wrong: This is false because `sys.path` is a built-in list, not a tuple. Unlike a tuple, a list is mutable, which allows programs to alter the import search path at runtime—for example, by calling `sys.path.append('/custom/path')` or inserting entries with `sys.path.insert(0, ...)`. This mutability is important for dynamic imports, but it also means the path list can be accidentally modified, affecting future imports.

The MRO is only used for methods, not attributes.

Why wrong: MRO affects attribute lookup as well, since attributes are looked up in the same order.

The MRO can be changed by modifying the class hierarchy at runtime.

Why wrong: MRO is fixed when the class is defined; altering parent classes later does not change MRO.

It must return a value.

Why wrong: The __init__ method must not return a value; its implicit return is always None. Attempting to return any non-None object from __init__ causes Python to raise a TypeError. This is because __init__ is responsible for initializing the newly created instance, not for producing the instance itself—that job belongs to __new__. Therefore, requiring __init__ to return a value is incorrect.

It is not inherited.

Why wrong: The __init__ method is inherited from a superclass; if a subclass does not define its own __init__, the parent's initializer will automatically be called when the subclass creates an instance. However, if a subclass defines its own __init__, the parent's is not automatically run unless the subclass calls super().__init__() explicitly. This behavior is a form of method inheritance, so the claim that __init__ is not inherited is categorically false.

Class attributes are always immutable.

Why wrong: A class attribute is simply a name bound to an object in the class namespace; nothing in Python prevents that object from being mutable. You can attach any value, including a list, dict, or set, all of which support in-place changes. For example, assigning `tags = []` in a class body creates a shared mutable list, and calling `obj.tags.append('x')` mutates that list. Thus, immutability is a property of the referenced object, not of the class attribute mechanism itself.

Class attributes are defined inside methods.

Why wrong: Class attributes are introduced by assignments executed directly in the class body, immediately after the class statement starts; they are not created by code written inside method definitions. An assignment like `self.value = 1` inside a method creates (or replaces) an instance attribute, while a bare `value = 1` inside the method is merely a local variable with no effect on the class. Methods can read or modify class attributes through `ClassName.attribute` or `self.__class__.attribute`, but defining them is not their job.

Modifying a class attribute via an instance modifies it for all instances.

Why wrong: The statement confuses two very different operations. If you execute `instance.attr = new_value`, Python binds a new attribute in that instance's `__dict__`, shadowing the class attribute for that instance only—the class-level binding is untouched. However, if the class attribute points to a mutable object, an in-place change like `instance.items.append(item)` mutates the shared object and is visible everywhere, but that is mutation, not reassignment. The claim as written describes reassignment behavior, which is incorrect because it does not propagate to other instances or the class.

Name mangling applies to all method names that start with a single underscore.

Why wrong: A single leading underscore is only a naming convention in Python, indicating that an attribute is meant for internal or protected use; it never triggers name mangling. Name mangling is specifically reserved for identifiers that begin with two or more leading underscores and have no more than one trailing underscore. Therefore, _method remains unchanged in the class namespace and is directly accessible under its original name, while __method is renamed.

Name mangling prevents external code from accessing the attribute entirely.

Why wrong: Name mangling does not enforce privacy; it is a textual renaming intended to reduce accidental name collisions in subclasses, not to block access. If you know the mangled form, such as _MyClass__secret, you can freely read or modify the attribute from outside the class. The original two-underscore name no longer exists in the object's namespace, so direct access like obj.__secret raises AttributeError, but the attribute itself is not hidden.

Name mangling occurs at runtime.

Why wrong: Name mangling is performed at compile time, when the class body is parsed and compiled into bytecode, not when code executes. It is a lexical substitution that replaces each qualifying identifier in the class namespace with its mangled form before any attribute lookup occurs. At runtime, the object contains only the mangled key, which is why hasattr(obj, '__attr') returns False even though _ClassName__attr exists.

s[0:5:2]

Why wrong: s[0:5:2] uses a step of 2 starting at index 0 and stopping before index 5, so it selects indices 0, 2, and 4. This yields the characters 'a', 'b', and '2', producing the string 'ab2' rather than only the digits. Because the first element is a letter, this slice does not match the target substring '123'.

s[0::2]

Why wrong: s[0::2] starts at index 0 with a step of 2 and continues to the end, so it takes indices 0, 2, and 4. Those positions hold the letters 'a', 'b', and 'c', making the result 'abc'. This fails because the step pattern from index 0 lands only on the letter characters, not the digits.

s[2:5:1]

Why wrong: s[2:5:1] uses a step of 1, meaning it is a contiguous slice from index 2 through index 4. The characters are 'b', '2', and 'c', producing 'b2c'. While it does contain the middle digit, it includes surrounding letters and skips the first and last digits, so it is not the desired '123'.

The `@override` decorator is required.

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

The subclass method can have a different number of parameters.

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

\x

Why wrong: Incomplete hex escape; must be followed by two hex digits.

\q

Why wrong: Not a recognized escape sequence; would be treated as literal backslash and q.

rstrip()

Why wrong: rstrip() removes trailing whitespace only.

trim()

Why wrong: trim() is not a method in Python strings.

clean()

Why wrong: clean() is not a method in Python strings.

bytearray

Why wrong: Bytearrays are mutable.

list

Why wrong: Lists are mutable.

from mypackage import bar.foo

Why wrong: Invalid syntax; cannot use dot after import.

from . import bar.foo

Why wrong: Invalid syntax; should be 'from .bar import foo'.

import mypackage.bar.foo

Why wrong: Importing a function directly with import statement is invalid; only modules/packages.

It imports the package itself as a module.

Why wrong: The star form `from package import *` does not bind the package name itself in the local namespace; it brings in the attributes defined in the package's `__init__.py`. The package object is already loaded and accessible under its own name after any import, but the star import never introduces that module reference. What you receive are the names contained within the package module, not the package module as a single object.

Without __all__, it imports all public names from the package's __init__.py and all submodules.

Why wrong: Without a defined `__all__`, `from package import *` imports every name from the package's `__init__.py` that does not begin with an underscore. However, this default filtering applies only to the package's own namespace; submodules are not automatically imported merely because the asterisk is used. Any submodule must be explicitly imported within `__init__.py` or explicitly listed in `__all__` to become available through the star import.

It imports all submodules of the package by default.

Why wrong: This statement is false because the default behavior of `from package import *` does not recursively import submodules or subpackages. The import system only examines the package's `__init__.py` file and imports the names defined there, respecting underscore-prefix exclusion unless `__all__` is present. To bring submodules into scope, you must either import them directly in `__init__.py` or include their names in the `__all__` list, otherwise they stay inaccessible through the star import.

The HOME environment variable

Why wrong: HOME is not directly used for sys.path.

The current working directory at runtime

Why wrong: Not added automatically; only the directory of the script is added.

`__bar__`

Why wrong: This is not a predefined special method in Python.

`__main__`

Why wrong: `__main__` is the name of the top-level script environment, not a method.

`__foo__`

Why wrong: This is not a predefined special method in Python.

s = "Line1\ Line2"

Why wrong: This is incorrect because the backslash at the end of the first line is a line-continuation escape, not a newline-inserting character. It tells Python to ignore the physical line boundary and continue parsing the same logical string literal on the next line, so the resulting value is 'Line1Line2'—a single-line string with no newline. Although the source code occupies two physical lines, the string itself contains no line break, so it is not a multiline string.

s = 'Line1 Line2'

Why wrong: This is invalid because a single-quoted string literal cannot span multiple physical lines in Python; the quote after Line1 closes the string, and Line2 is parsed as a separate, unexpected token, causing a SyntaxError. Raw newlines inside a standard string literal are forbidden—they must be escaped as \n or the string must use triple quotes. Thus this source code does not compile.

It eliminates the need for try/finally blocks for resource management.

Why wrong: It is an alternative, but try/finally may still be used for other purposes.

It can only be used with file objects.

Why wrong: Can be used with any context manager, e.g., locks, database connections.

str.join()

Why wrong: str.join() returns a new string that is the concatenation of an iterable's elements, joined by the separator string; it does not modify any string in place.

str.replace()

Why wrong: str.replace() returns a new string with occurrences of a substring replaced; it does not modify the original.

str.strip()

Why wrong: str.strip() returns a new string with leading and trailing characters removed; it does not modify the original.