Scenario practice questions

All imports should be sorted alphabetically regardless of origin.

Why it fails: PEP 8 does not recommend sorting all imports alphabetically without regard to origin. Instead, it emphasizes grouping by origin (standard library, third-party, local) and then sorting alphabetically within each group. Sorting all imports together would mix standard library and third-party modules, making it harder to see dependencies and potentially causing confusion.

Imports should be placed on separate lines, and no blank lines are needed between groups.

Why it fails: While PEP 8 does recommend placing imports on separate lines (except for `from` imports of multiple items), it also advises separating groups with a blank line. Omitting blank lines would reduce readability and make it harder to distinguish between standard library and third-party imports. The correct practice is to group and separate with blank lines.

Third-party imports first, then standard library imports, to highlight external dependencies.

Why it fails: PEP 8 recommends the opposite: standard library imports should come first, followed by third-party imports. Putting third-party imports first would not align with the convention and could make it less clear which modules are part of the standard library. Consistency with the broader Python community is important, so standard library imports should lead.

root.bind_class('Entry', '<Escape>', on_cancel)

Why it fails: bind_class associates the handler with a widget class, so it only triggers for Entry widgets and only when one of them has focus. It does not cover Buttons, Labels, or the root window, so pressing Escape while focus is elsewhere would not invoke on_cancel, failing the global requirement.

entry.bind('<Escape>', on_cancel)

Why it fails: Binding to the Entry widget only fires when that widget has keyboard focus. If focus moves to a Button or the dialog itself, the handler will not run, so the requirement of reacting at any time is not satisfied. A widget-level binding is too narrow for a global cancel key.

root.bind('<Escape>', on_cancel, add='+')

Why it fails: Binding on the root window only fires when the root itself has focus, which is rarely the case when an Entry has keyboard focus. The add='+' parameter merely preserves existing bindings for the same sequence; it does not widen the scope, so the handler will not run while the user is typing in the Entry.

It is required for private methods.

Why it fails: super() has no special relationship with private methods; name-mangled attributes remain accessible via the mangled name regardless. It is tempting because super() does resolve names dynamically, but its purpose is cooperative multiple inheritance, ensuring the next class in the MRO is invoked rather than a hard-coded parent.

It is faster.

Why it fails: super() carries lookup overhead through the MRO rather than being faster; direct calls can be marginally quicker. It is tempting because super() avoids repeating the parent's name, but its actual benefit is correct cooperative multiple inheritance, not performance.

It makes the code more verbose.

Why it fails: Verbosity is not the purpose of super(); it resolves the next class in the method resolution order, which matters for multiple inheritance and cooperative methods. Calling the parent by name hard-codes one ancestor and breaks diamond hierarchies. The option is tempting because super() does add a line, but its benefit is MRO correctness, not brevity.

Move the validation into a separate thread and call dialog.destroy() from that thread when validation fails.

Why it fails: Tkinter widgets are not thread-safe, and calling destroy() from a worker thread can corrupt the interpreter or raise RuntimeError about being called from a different thread. Threading also does not address the real issue, which is exception handling inside the callback. The dialog would still be closed on failure, and the inline error label would never be shown reliably.

Call dialog.wait_window(dialog) again inside the OK button command so the dialog blocks until validation succeeds.

Why it fails: wait_window is already active on the dialog from the caller side; nesting another wait_window inside the callback creates a reentrant event loop that can lead to confusing focus and modal behavior. It does not catch ValueError, so the exception still escapes the callback. The error label would not be updated, and the dialog could become unresponsive to the user's corrections.

Set dialog.protocol('WM_DELETE_WINDOW', lambda: None) so the dialog cannot be closed while validation is pending.

Why it fails: Overriding the window-close protocol only affects the title-bar close button; it has nothing to do with exceptions raised in the OK callback. The ValueError would still propagate out of the callback and be routed to report_callback_exception, leaving the error label untouched. This approach also traps the user in a dialog they cannot dismiss, which is a poor user experience.

requests.get('https://api.example.com/v1/items', timeout=30)

Why it fails: A single numeric timeout sets both the connect and read timeouts to the same value. Using 30 would allow up to 30 seconds just to establish the connection, which is far more lenient than the required 5 seconds. It does not satisfy the asymmetric timeout requirement described in the scenario.

requests.get('https://api.example.com/v1/items', timeout=(30, 5))

Why it fails: The tuple order matters: the first element is the connect timeout and the second is the read timeout. Reversing them would allow 30 seconds to connect and only 5 seconds to read, which is the opposite of what the scenario requires. This would likely cause read timeouts on slow responses.

requests.get('https://api.example.com/v1/items', timeout=5, read_timeout=30)

Why it fails: requests.get does not accept a read_timeout keyword argument. Passing an unrecognized keyword raises a TypeError before the request is even sent. The library only exposes the timeout parameter, which can be a single value or a (connect, read) tuple. This call fails at the Python level, not at the network level.