Python 3.6.3 preserves the errors a program needs to diagnose

An exception can reach the right handler and still lose the information needed to explain the failure. Replacing a specific lookup error with KeyError, dropping an SSL error number, or pointing a warning at the wrong line all change what a developer can infer from a failing program. Python 3.6.3 includes corrections in each of these areas. They improve the account of a failure without asking applications to adopt new error-handling syntax.

The release page dates the maintenance update to October 3. Its candidate change record in the release tag identifies the relevant fixes individually. Reading them together shows a practical maintenance concern. Intermediary code must preserve the error raised by the operation it delegates to, or replace it only where the interface actually requires that replacement.

I value Python's protocol machinery when a library can accept an object through an ordinary method. That machinery also creates several opportunities to hide the actual cause of a failure. A wrapper that preserves the original exception is easier to reason about than one that reports every failure as the same missing value.

A mapping lookup can fail for several reasons

Issue 30978 changes str.format_map() to pass through exceptions raised during key lookup. The NEWS entry says the previous behavior replaced any exception with KeyError. That replacement discards a distinction between a genuinely missing key and an error encountered while calculating or retrieving a value.

A mapping can implement behavior behind its lookup operation. If that operation raises an application-specific exception, replacing it changes the information that reaches the caller. The caller may have a handler for the original error or may need its message to diagnose the failure. Preserving the exception allows the object implementing the mapping to express why it could not supply the requested value.

This does not mean a missing key stops being an error. It means the formatting method no longer forces every possible lookup failure into that category. The correction preserves the underlying operation's account of the problem. That is particularly useful when the mapping's behavior is more complicated than accessing a pre-populated dictionary.

Issue 31071 addresses a related loss of information in calls using starred argument unpacking alongside other arguments. It avoids masking an original TypeError. The release note identifies the call arrangement and the exception being obscured, so it is narrower than a general promise that all exception chains have changed. Both fixes reduce the chance that machinery around an operation replaces its useful diagnostic.

Source locations are part of a language feature

Formatted string literals contain expressions inside a string-oriented construct. Tools inspecting those expressions need locations that refer back to the program being examined. Issue 30465 makes f-string line and column information mostly correct. The release note specifically mentions tools such as flake8 previously showing warnings at the wrong line, often the file's first line.

The word mostly in the change record is worth preserving. This is an improvement to location reporting, not a claim that every possible f-string position is now perfect. A diagnostic's source location is nevertheless an operational part of the feature. A tool can identify a real problem but impose substantial extra work if it directs the developer to an unrelated line.

The fix belongs in the interpreter because tools consume the location information it supplies. Each tool independently guessing where an expression originally appeared would duplicate the work and risk inconsistent answers. Correcting the source of that information improves the input available to those tools.

SSL failures retain library details

Issue 31400 improves SSL error handling to avoid losing error numbers. Issue 28958 makes ssl.SSLContext() use OpenSSL error information when context creation fails. A context can fail before an application establishes a connection, so useful diagnostics need to exist during configuration as well as during network traffic.

These changes preserve distinctions supplied by the underlying TLS library. They do not make every context configuration valid or promise a different network outcome. Instead, an unsuccessful operation reports more of the evidence available at the point of failure. That matters when configuration and linked-library behavior differ between environments.

I prefer this kind of correction to application advice that treats all TLS failures as interchangeable. The library has specific error information, and exposing it gives the application a better basis for understanding what failed. A maintainer should not have to reproduce a problem with extra instrumentation merely because an intermediate layer discarded an existing error number.

The release also sets the filename on POSIX FileNotFoundError raised by subprocess when the executable or working directory cannot be found, under issue 22536. That brings another failure back to the input that caused it. The common benefit across these corrections is concrete information attached to an error, whether that information is its original type, its source position, or the pathname involved. Python 3.6.3 improves those particular diagnostic paths while retaining the existing programming interfaces around them.