Select Two (Multi-Select) Questions

The docstring should be a single line that ends with a period.

Why it fails: PEP 257 recommends that a one-line docstring should end with a period, but it does not require all docstrings to be single-line. Multi-line docstrings are common for complex functions. The key is that the first line should be a concise summary, and it should end with a period if it is a one-liner.

The docstring should be separated from the function definition by a blank line.

Why it fails: PEP 257 explicitly states that there should be no blank line before the docstring; it should immediately follow the function definition line. A blank line after the docstring is acceptable, but not before. This ensures the docstring is directly associated with the function.

The docstring should be written in all uppercase letters.

Why it fails: There is no such requirement in PEP 257. Docstrings should be written in normal sentence case, following standard English capitalization. Using all uppercase would be unusual and not recommended. The focus is on clarity and consistency, not on capitalization style.

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.

Writing docs only at the end of the project.

Why it fails: Documentation written only at the end drifts from the code and misses decisions made during development, so it cannot be maintained alongside changes. It is tempting when deadlines pressure teams to ship first, and it would suit a short, throwaway script where no ongoing maintenance is expected.

Keeping documentation in a separate repository.

Why it fails: A separate repository decouples docs from the code they describe, so version changes are not committed together and drift goes unnoticed. It is tempting because it isolates tooling and access control, and it would be correct for organisation-wide standards or policies that span many unrelated projects.

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 manager automatically ignores the order in which pack() is called.

Why it fails: Packing order determines placement: the first widget packed claims the first cavity along the specified side, so call sequence directly controls layout. The option is tempting because pack does reflow widgets when the window resizes, which can look like order being disregarded, but that reflow preserves packing sequence.

Widgets are placed in a grid coordinate system.

Why it fails: pack allocates widgets along a single side of their container, stacking them in order; grid coordinates belong to the grid manager. It is tempting because grid-like layouts are common, and mixing pack and grid in one container is a frequent mistake, but pack itself never uses rows and columns.

Widgets are positioned at exact X and Y coordinates.

Why it fails: pack positions widgets relative to their container's sides using fill, expand, side and anchor; absolute X/Y placement belongs to the place manager. It is tempting because precise pixel positioning is sometimes needed, where place would be correct, but pack never accepts explicit coordinates.

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.

Using a global variable that is not initialized.

Why it fails: An uninitialised global variable provides no instance control: any module can rebind it, and nothing prevents multiple constructions. It is tempting because module-level globals are Python's simplest shared-state idiom, and a pre-declared name can later hold a singleton instance. That pattern suits lazy configuration flags, not enforcing exactly one instance across all import paths.

Using a function that returns a new instance every call.

Why it fails: Returning a fresh instance on each call directly contradicts the singleton requirement that all callers receive the same object, so identity comparisons fail. It is tempting because factory functions legitimately encapsulate construction and are the right choice when independent, short-lived instances are wanted rather than one shared instance.

Using a standard class without any special methods.

Why it fails: A plain class instantiates a fresh object on every call, so no single shared instance exists — the defining requirement of a singleton. It is tempting because ordinary classes are the default building block, and would be correct when independent instances are wanted, such as value objects or per-request handlers where shared state is undesirable.

Constants: camelCase

Why it fails: PEP 8 specifies UPPER_CASE_WITH_UNDERSCORES for constants, so camelCase contradicts the documented convention. camelCase is tempting because it is the standard for constants in languages such as Java and JavaScript, making it the correct choice when writing code in those ecosystems rather than Python.

Modules: PascalCase

Why it fails: PEP 8 specifies short, all-lowercase module names, with underscores only if readability demands; PascalCase is reserved for classes. It tempts because PascalCase module files appear in some frameworks, but that practice deviates from the documented convention.

Functions: camelCase

Why it fails: PEP 8 prescribes lowercase_with_underscores for function names; camelCase belongs to languages such as Java. It tempts because many Python libraries expose camelCase callables inherited from C or Java APIs, making the style look acceptable despite contradicting the standard.

A list of strings to write.

Why it fails: writerow accepts any iterable, including tuples and generators, so a list of strings is not required. It is tempting because lists are the common literal form in examples, and would be the correct choice when the row's fields are already collected as a mutable sequence before writing.

A call to csv.close().

Why it fails: csv has no close() function; the underlying file object is closed instead, so this call cannot exist. It is tempting because closing a resource after writing is normal practice elsewhere, and would be the right step when you opened the file yourself and must flush buffered rows to disk.

A predefined dialect.

Why it fails: Writing needs only a file object and a row; csv.writer infers comma delimiters when no dialect is supplied, so a predefined dialect is optional. It is tempting because dialects exist to customise delimiters, quoting and line endings — the right choice when output must match a non-comma format such as tab-separated data.

socket

Why it fails: Response exposes parsed content, status_code, headers and cookies; the underlying transport socket is not a documented attribute, though it is reachable via raw internals. It tempts because requests does wrap a urllib3 connection, so a socket exists somewhere beneath, but that is implementation detail rather than part of the public Response interface.

connect()

Why it fails: connect() is a method on Session and HTTPAdapter, not an attribute of Response; Response exposes status_code, headers, text and json(). It is tempting because connection handling is part of the requests workflow, but it belongs to the transport layer, not the returned response object.

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.

Place the function at the top of the file, before any imports, to make it easily accessible.

Why it fails: PEP 8 recommends that imports be placed at the top of the file, after any module docstring and before other code. Placing a function before imports would violate this convention and could lead to NameErrors if the function relies on imported modules. This option is incorrect because it disregards the standard file structure that Python developers expect, which can cause confusion and potential runtime errors.

Raise a generic `Exception` if the file cannot be read, to keep error handling simple.

Why it fails: Raising a generic `Exception` is discouraged because it makes it difficult for callers to handle specific errors. PEP 8 and best practices suggest raising the most specific exception possible, such as `FileNotFoundError` or a custom exception. This allows for precise error handling and better debugging. This option is incorrect because it promotes a vague error handling strategy that can lead to brittle code.

Use a single-letter parameter name like `f` for the file path to keep the signature short.

Why it fails: PEP 8 advises using descriptive names for parameters to make code more readable. A single-letter name like `f` is ambiguous and does not convey that it represents a file path. While short names can be acceptable for local variables in small scopes, function parameters should be clear, especially in public APIs. This option is incorrect because it sacrifices clarity for brevity, violating PEP 8's emphasis on readability.

block

Why it fails: 'block' is not a Tkinter geometry manager; the three valid ones are pack, grid and place. It may sound plausible because pack and grid both arrange widgets in blocks, but no manager named block exists, so calling it raises an error.

align

Why it fails: Tkinter's geometry managers are pack, grid and place; align is not one, so it cannot position widgets at all. It tempts because alignment sounds like layout, and CSS or other toolkits expose alignment properties, but Tkinter achieves alignment through pack's anchor and side options or grid's sticky.

flow

Why it fails: flow is not a Tkinter geometry manager; only pack, grid and place exist, and none lays widgets out in a wrapping flow. It tempts because flow-based layout is familiar from CSS flexbox and Java's FlowLayout, which would be the right mental model there, but Tkinter offers no such manager.

It works by implicit __init__ calling.

Why it fails: The with statement calls __enter__ on entry and __exit__ on exit; __init__ runs at object construction, before with is evaluated, so it plays no part in the protocol. Confusing construction with context entry is the trap. The statement would be accurate if it described __enter__ and __exit__ invocation instead.

It only works with file objects.

Why it fails: The context manager protocol is implemented by any class defining __enter__ and __exit__, so files are merely the most common example; custom classes, locks, sockets and database connections all qualify. Restricting it to file objects would make resource-management helpers impossible. It would be the right statement only if the protocol were file-specific.

It can be used with any object.

Why it fails: Any object can be used only if its class implements __enter__ and __exit__; otherwise Python raises AttributeError. The claim overstates the protocol, since arbitrary objects such as plain integers or strings lack those methods. It would hold if qualified as any object supporting the context manager protocol.

It automatically creates a transaction for every SELECT.

Why it fails: sqlite3 opens transactions implicitly before INSERT, UPDATE, DELETE and REPLACE statements, not SELECT, which is read-only and requires no transaction. The confusion arises because Python's DB-API modules do autocommit-style handling. A Cursor would be relevant to transaction control when executing data-modifying statements.

It is limited to one active query.

Why it fails: A single Cursor can execute many statements sequentially and hold multiple result sets; only one statement executes at a time, but that is not a limit of one active query overall. The claim is tempting because cursors are often used one query at a time. Multiple cursors on one connection are supported.

It keeps track of the connection state.

Why it fails: The Connection object tracks connection state, transaction status and commit behaviour; the Cursor is a statement handle that executes SQL and fetches rows. Confusing the two is tempting because cursors are obtained from connections. A Cursor would be correct when you need to iterate result sets or manage per-statement execution.

ttk.Window

Why it fails: ttk.Window does not exist; the themed module provides widgets and styles, while the top-level window remains tkinter.Tk (or Toplevel). It is tempting because ttk does supply themed containers such as Frame and Labelframe, so a window-like name appears plausible, but the correct choice would be a genuine ttk widget class.

ttk.Canvas

Why it fails: Canvas belongs to classic tkinter, not ttk; the themed module offers no Canvas widget. It is tempting because ttk does provide themed equivalents of many classic widgets, so assuming Canvas was ported seems reasonable, but the correct choice would be a widget class ttk actually implements, such as Treeview or Notebook.

row

Why it fails: pack() accepts side values 'top', 'bottom', 'left' and 'right'; 'row' is a grid() parameter, not a pack() one. It tempts because grid() positions widgets by row and column, making 'row' feel like a natural layout argument across both geometry managers.

column

Why it fails: pack() accepts side values 'top', 'bottom', 'left' and 'right', plus fill, expand, anchor, ipadx, ipady and padx/pady; 'column' belongs to grid(). It tempts because grid() uses column and row coordinates, so mixing the two geometry managers' vocabularies is a common error.

Public IP Whitelisting

Why it fails: IP whitelisting restricts which networks may connect but transmits no credential, so the API cannot identify the caller; it is network-layer access control, not authentication. It is tempting because it hardens an endpoint cheaply, and it would be correct as a defence-in-depth layer alongside token or key authentication.

Hardcoding passwords in code

Why it fails: Embedding credentials in source code exposes them to anyone with repository access and prevents rotation without redeployment; it is not an authentication mechanism at all. It is tempting because it is the quickest way to make a script authenticate during local development, but even there environment variables or a secrets manager should replace it.