Hard Difficulty Questions

Wrap the session object in a threading.Lock

Why it fails: A Lock serialises every request through one session, destroying the concurrency threading was introduced to provide. It is tempting because shared mutable state normally needs locking, but requests.Session is designed for concurrent use; the correct pattern is one session per thread, avoiding cross-thread contention.

Share a single global Session object across all threads

Why it fails: A Session is not thread-safe; sharing one globally across threads risks corrupted connection-pool state and interleaved cookie handling. It is tempting because a single session maximises connection reuse, and would be correct in single-threaded code or when each thread creates its own Session instance.

Disable connection pooling using 'pool_connections=0'

Why it fails: Setting pool_connections=0 removes connection reuse entirely, forcing a fresh TCP and TLS handshake per request and defeating the purpose of session persistence. It is tempting as a crude way to avoid cross-thread pool contention, and would be correct only if pooling itself caused the fault being diagnosed.

Encrypt the secrets and store them as constants in a module.

Why it fails: Encrypted constants still ship inside the repository, and the decryption key must reside somewhere equally accessible, so the secret remains recoverable from source. It is tempting because encryption sounds protective, and it is appropriate for data at rest in storage rather than credentials embedded in application code.

Store secrets in a private class attribute.

Why it fails: A private class attribute is only name-mangled, remaining readable via _ClassName__secret and exposed in memory dumps, so it fails the sensitive-operations requirement. It is tempting because encapsulation suggests protection, and private attributes are appropriate for hiding ordinary internal implementation details from callers.

Hardcode them as strings inside a 'config.py' file and ignore it in Git.

Why it fails: Git-ignoring config.py leaves the secret in plaintext on disk and in every deployment artefact, readable by anyone with filesystem access. It is tempting because ignoring the file keeps secrets out of version control, which is appropriate for local development configuration, not production key management.

Pass copy_function=shutil.copyfile to shutil.copytree() so existing files are never overwritten.

Why it fails: shutil.copyfile() still opens the destination for writing and truncates it, so existing files are overwritten. It also copies only file contents, discarding permissions and timestamps, which directly violates the metadata requirement. Choosing copyfile therefore fails both stated goals: it neither preserves metadata nor prevents overwriting of conflicting files.

Pass dirs_exist_ok=True to shutil.copytree() so the copy proceeds when the destination directory already exists.

Why it fails: dirs_exist_ok=True does the opposite of failing loudly: it allows copytree() to merge into an existing destination directory instead of raising FileExistsError. It says nothing about individual file conflicts, and it permits overwriting of same-named files. For this scenario, leaving dirs_exist_ok at its default False is what produces the explicit failure when the destination already exists.

Pass copy_function=shutil.copy to shutil.copytree() so only permission bits are carried over.

Why it fails: shutil.copy() copies file contents plus permission mode, but it does not preserve timestamps or flags the way copy2 does through copystat, so metadata preservation is incomplete. It also overwrites an existing destination file rather than raising an error. This option addresses only part of the metadata requirement and none of the conflict requirement.

requests.post(token_url, json={'grant_type': 'client_credentials', 'client_id': cid, 'client_secret': secret})

Why it fails: Using json= sets the Content-Type to application/json and serializes the payload as JSON. The authorization server in this scenario requires application/x-www-form-urlencoded, so it would reject the request or fail to parse the parameters, resulting in an invalid_client or invalid_request error.

requests.post(token_url, auth=(cid, secret), data={'grant_type': 'client_credentials'})

Why it fails: Passing auth=(cid, secret) sends the credentials via HTTP Basic authentication in the Authorization header, not in the request body. While some OAuth servers accept Basic auth for client authentication, the scenario explicitly states the server expects the credentials in the form-encoded body, so this call does not meet the requirement.

requests.get(token_url, params={'grant_type': 'client_credentials', 'client_id': cid, 'client_secret': secret})

Why it fails: OAuth 2.0 token endpoints require a POST request, not GET. Placing credentials in the query string also exposes them in server logs and browser history, which is a security anti-pattern. This call would likely return 405 Method Not Allowed and would not obtain a token.

The child class will raise an error at instantiation.

Why it fails: Python permits subclassing a slotted parent freely; instantiation succeeds and the child simply gains a __dict__ unless it declares __slots__. Raising an error occurs only for genuine slot conflicts, such as a slot name colliding with a class variable, so this scenario does not trigger it.

The child class will inherit the memory savings automatically.

Why it fails: Slot descriptors are not inherited for memory purposes: a child without its own __slots__ regains a __dict__, so instances consume extra memory per object. Declaring __slots__ in the child as well is what preserves the saving, making this the correct choice only when every subclass in the hierarchy repeats the declaration.

The child class will be unable to add new attributes.

Why it fails: A child lacking its own __slots__ receives a __dict__, so arbitrary new attributes can still be assigned to its instances. Attribute restriction applies only when the child itself declares __slots__, which is the configuration required when memory footprint and fixed attribute sets must be enforced.

It speeds up data transmission

Why it fails: SO_REUSEADDR lets a socket bind to a local port still in TIME_WAIT, avoiding 'Address already in use' on restart; it changes no transmission path, so throughput is untouched. It is tempting because socket options are often assumed to tune performance, and TCP_NODELAY genuinely reduces latency by disabling Nagle's algorithm.

It enables broadcasting on the socket

Why it fails: SO_REUSEADDR governs rebinding a local address in TIME_WAIT; broadcast permission comes from SO_BROADCAST, which is required before sending to a broadcast address. It is tempting because both are socket-level options set via setsockopt, and reuse of an address can be confused with reaching multiple hosts simultaneously.

It prevents the socket from closing

Why it fails: SO_REUSEADDR manipulates bind-time address reuse, not connection lifetime; it never stops a socket closing, so it cannot satisfy a question about that behaviour. It is tempting because the name suggests resource persistence, and it genuinely matters when restarting a server whose listening port sits in TIME_WAIT, allowing an immediate rebind.

zipf.write('/data/reports/summary.txt')

Why it fails: Without arcname, the file is stored using its full path, which may include leading slashes or drive letters, and typically results in an entry like '/data/reports/summary.txt' or 'data/reports/summary.txt'. This does not match the desired 'reports/summary.txt' and may create absolute paths in the archive, which is undesirable.

zipf.add('/data/reports/summary.txt', 'reports/summary.txt')

Why it fails: The zipfile module does not have an add() method. The correct method is write(). This option is invalid because it calls a non-existent method, resulting in an AttributeError. The write() method is used to add files to a ZIP archive.

zipf.write('/data/reports/summary.txt', arcname='summary.txt')

Why it fails: This adds the file with the arcname 'summary.txt', placing it at the root of the archive. It does not preserve the 'reports/' directory structure. The arcname parameter controls the name inside the archive, so specifying only the basename loses the directory hierarchy.

It does not support HTTPS

Why it fails: requests fully supports HTTPS, verifying certificates by default via certifi and exposing the verify parameter. It is tempting to assume otherwise because certificate errors surface frequently in practise, but those indicate misconfiguration, not absent TLS support; urllib also handles HTTPS.

It is part of the standard library

Why it fails: requests is a third-party package installed via pip, not bundled with CPython, so it must be imported after separate installation. It is tempting because its ubiquity and clean API make it feel native, but the standard library's equivalent is urllib.request, which ships with Python.

It is thread-safe by default for all operations

Why it fails: requests uses a shared Session object whose connection pool and cookie handling are not guaranteed thread-safe for concurrent writes, so callers must synchronise or use separate sessions. It is tempting because simple GET calls often appear to work concurrently, but thread safety is not a documented default guarantee.

The exception is ignored by the ThreadPoolExecutor

Why it fails: Exceptions raised inside a worker thread are captured and stored in the Future, then re-raised when result() or exception() is called; they are not silently discarded. It is tempting because unretrieved Futures hide failures, but the executor itself always records the exception.

The entire program crashes immediately

Why it fails: An exception inside a worker thread is captured in the Future object and re-raised only when result() is called; other threads and the main program continue running. The option is tempting because unhandled exceptions in raw threading can terminate a thread, but ThreadPoolExecutor deliberately isolates them per task.

The thread dies silently without notification

Why it fails: ThreadPoolExecutor stores the exception in the returned Future, re-raising it when result() is called, so failures surface rather than vanishing. The silent-death idea tempts because raw threading threads do print a traceback and continue, but futures deliberately capture exceptions for the caller to retrieve.

command=my_func(arg1=value)

Why it fails: Tkinter invokes the command callback with no arguments, so keyword arguments passed at assignment time raise TypeError when the button is clicked. It tempts because keyword arguments are valid Python syntax generally, but Tkinter requires a zero-argument callable, typically wrapped in lambda or functools.partial.

command=my_func(arg1)

Why it fails: Writing command=my_func(arg1) calls my_func immediately during widget construction and assigns its return value, so the button never invokes the function. It tempts because the syntax resembles a normal call, but Tkinter needs a callable reference, achieved via lambda or functools.partial.

os.path.normpath()

Why it fails: os.path.normpath() normalizes a path by collapsing redundant separators and up-level references, but it does not make the path absolute. If given a relative path, it returns a relative path. It does not prepend the current working directory. Thus, it cannot be used to obtain an absolute path. It is useful for cleaning up paths, but not for making them absolute.

os.path.realpath()

Why it fails: os.path.realpath() returns the canonical path by resolving all symbolic links and '..' components. While it provides an absolute path, it also resolves symlinks, which is not desired in this scenario. Using it would give a different result if the path contains symlinks. Therefore, it does not meet the requirement of avoiding symlink resolution.

os.path.join()

Why it fails: os.path.join() intelligently joins one or more path components, but it does not convert a relative path to an absolute one. It simply concatenates the components with the appropriate separator. If you provide a relative path, the result remains relative. Therefore, it does not fulfill the requirement of obtaining an absolute path without resolving symlinks.

parser = ConfigParser(case_sensitive=True)

Why it fails: ConfigParser accepts no case_sensitive keyword; option names are lowercased by default via optionxform. It is tempting because it mirrors the intuitive parameter name, and would be correct if the library exposed such a flag, but the actual mechanism is overriding optionxform with str.

parser.set_case(True)

Why it fails: ConfigParser defines no set_case method, so this raises AttributeError rather than altering casing behaviour. It is tempting because it reads like a plausible API call for toggling case handling, and would be correct if such a setter existed, but casing is controlled by overriding optionxform.

parser.read(file, case='preserve')

Why it fails: read() accepts only filenames, so a case keyword raises TypeError; casing is controlled by setting parser.optionxform to str before reading. The option is tempting because it resembles a plausible API parameter, but configparser exposes no per-call casing argument.

Every time an instance method is called.

Why it fails: Instance method calls resolve through the class's __getattribute__ and descriptor protocol, never the metaclass. A metaclass __call__ intercepts instantiation of the class itself. It is the right hook when you must customise what happens each time an object is constructed.

When the metaclass is first imported.

Why it fails: Import merely executes the module body, defining the metaclass; __call__ is not invoked then. The metaclass's __call__ fires on each instantiation of classes that use it. Import-time behaviour would instead be handled by module-level code or a metaclass __init__.

When the class itself is defined.

Why it fails: The metaclass's __call__ runs when the class is instantiated, intercepting construction of instances. Class definition instead triggers __new__ and __init__ on the metaclass. Overriding __call__ is correct when you need to control or wrap instance creation, such as implementing singletons.

Use response.json() directly; it automatically streams and parses the JSON without loading everything into memory.

Why it fails: 'response.json()' reads the entire response body into memory before parsing it into a Python object. For large responses, this can exhaust memory. It does not provide incremental parsing. While it is convenient for small responses, it is not suitable for the scenario where memory efficiency is required. You need a streaming approach instead.

Use requests.get() with a large timeout and rely on the operating system's memory management to handle the response.

Why it fails: A timeout controls how long to wait for the server to send data, not how the data is buffered. The operating system does not automatically parse JSON incrementally; the entire response will still be loaded into memory by 'requests' unless 'stream=True' is used. Relying on OS memory management is not a valid strategy for handling large JSON responses efficiently.

Set stream=True and then call response.json() to parse the streamed data.

Why it fails: Even with 'stream=True', calling 'response.json()' will consume the entire stream and load it into memory to parse the JSON. The 'stream' parameter only defers the download of the body until you access 'response.content' or iterate. It does not make 'response.json()' stream-aware. Therefore, this still results in high memory usage and is not the correct technique.

OAuth 2.0 access tokens are typically sent as query parameters in the URL.

Why it fails: While some APIs allow tokens as query parameters, it is insecure because URLs can be logged or cached. The OAuth 2.0 specification recommends sending tokens in the 'Authorization' header using the Bearer scheme. Using query parameters exposes the token in server logs, browser history, and referrer headers, making it a poor practice and often discouraged by API providers.

The 'requests' library automatically refreshes expired OAuth 2.0 tokens when using the 'auth' parameter.

Why it fails: The 'auth' parameter in 'requests' is for HTTP Basic Authentication (username/password) or custom authentication classes, not OAuth 2.0. It does not handle token refresh. Automatic refresh requires a library like 'requests-oauthlib' that implements the OAuth 2.0 flow, including refresh tokens. Assuming 'auth' handles OAuth would result in failed requests once the token expires.

The 'requests' library includes built-in support for OAuth 2.0 token management.

Why it fails: The core 'requests' library does not include OAuth 2.0 support out of the box. While it can send Authorization headers, it does not handle the OAuth dance (authorization code exchange, token refresh, etc.). You need an external library like 'requests-oauthlib' or implement the flow manually. Assuming built-in support would lead to incomplete implementations.

Use 'subprocess' with 'shell=True'.

Why it fails: shell=True passes the command string to the system shell, enabling shell injection when any part derives from untrusted input. It tempts developers wanting shell features like pipes or globbing, where shell=True is acceptable only with fully static, developer-controlled command strings.

Always use 'eval()' for dynamic execution.

Why it fails: eval() executes arbitrary Python expressions, so untrusted input yields remote code execution; ast.literal_eval() or json parsing is the safe substitute. It tempts developers needing quick dynamic evaluation, where eval() is defensible only on constants the program itself generates.

Use hardcoded credentials for database connections.

Why it fails: Hardcoded credentials leak through source control, logs and container images, and cannot be rotated without redeployment. It tempts developers prototyping locally where speed matters, but secrets belong in environment variables or a managed vault such as Azure Key Vault.

Using 'finally' for cleanup.

Why it fails: Using 'finally' for cleanup is idiomatic Python, not a smell: it guarantees release of files, locks or connections whether or not an exception propagates. It only becomes questionable when a bare 'return' inside 'finally' swallows the original exception, but that is a control-flow defect, not the construct itself.

Catching specific exceptions.

Why it fails: Catching specific exceptions is the recommended practise, because it avoids masking unrelated failures such as 'KeyboardInterrupt' or 'MemoryError'. It only becomes a smell when the handler is empty or merely logs and re-raises nothing, silently discarding the error condition the caller needed to see.

Raising custom exceptions.

Why it fails: Raising custom exceptions is encouraged, since it lets callers catch domain-specific failures rather than inspecting message strings. It becomes a smell only when the custom class subclasses 'Exception' directly instead of a meaningful base, or when it is raised for ordinary control flow that 'if' statements should handle.

To signal that the server is alive

Why it fails: The Connection header controls whether the TCP connection persists or closes after a response; it does not report server liveness, which is detected through response receipt or health checks. Keep-alive negotiation is its actual purpose, making this option a misreading of the header's role in persistent connections.

To encrypt the connection

Why it fails: Encryption is provided by TLS, not by the Connection header, which merely signals hop-by-hop persistence or closure. Confusing transport security with connection management leads to this error; the header's role is keep-alive negotiation, not cryptographic protection.

To set the timeout for the connection

Why it fails: The Connection header carries directives such as keep-alive or close; it does not define timeouts, which are governed by socket or server settings. Timeout configuration is handled outside HTTP semantics, so this option misattributes the header's function when persistent connection control is required.

To allow private methods.

Why it fails: Name mangling for double-underscore attributes is applied by the compiler, and single-underscore privacy is convention only; ABCMeta has no role in either. It is tempting because abstract base classes often hide internal helpers, but ABCMeta would be correct when you need to prevent instantiation of a class that has unimplemented abstract methods.

To improve method resolution speed.

Why it fails: ABCMeta exists to register virtual subclasses and enforce abstract method implementation at instantiation, not to alter method lookup performance; the C3 linearisation and method cache govern resolution speed. It is tempting because metaclasses do sit in the class-creation path, and a custom metaclass would be the right tool for injecting behaviour into class construction.

To support multiple inheritance.

Why it fails: Multiple inheritance works through C3 linearisation in ordinary classes; ABCMeta adds no support for it, only abstractmethod enforcement and virtual subclass registration. It is tempting because abstract base classes are frequently combined with mixins, and ABCMeta would be the correct choice when you need to declare an interface that subclasses must fully implement.

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.