String formatting: new conversion specifier 'e'

Ideas
1

I’d like to propose a new conversion flag ‘e’ (e as an exception). Even if it might be regarded as yet another syntax sugar proposal, IMO the benefit is not just few characters saved.

If an expression to be formatted for output raises an exception during its evaluation or the formating itself fails, the exception is propagated as usual. This is desired in most cases, but not all.

The proposed conversion flag is really simple and all it does is it arranges that Exceptions (but not BaseExceptions) are caught and if that happens, the exception is printed instead of the unavailable value of the expression. EAFP principle fine-grained.

# first example
a = 1; b = 0
print(f"value1={a} ratio={a/b}")
# raises an exception; value1 not printed (lost); next statement not reached

# with 'e'
print(f"value1={a} ratio={a/b!e}")
# prints: value1=1 ratio=ZeroDivisionError('division by zero')
# program continues normally

# second example
speed = None # could not read the gauge
print(f"speed={speed:.1f}") # exception

# with 'e'
print(f"speed={speed!e:.1f}")
# prints: speed=TypeError('unsupported format string passed to NoneType.__format__')

Notes:

  • Actually, ‘e’ is a pseudo-conversion flag, because no value conversion is done (real conversions are taking place before formatting). It may be combined with existing flags ‘a’, ‘r’ and ‘s’.

  • It is intended mainly for output of human readable strings, not machine parseable output.

This is a modified version of a proposal that was submitted a year ago, but could not be discussed here in “ideas”, becase the moderators moved the thread to another place. Anyway, there was some feedback I briefly summarized below so we don’t have to refer to the old thread:

Objection 1: It is possible to evaluate each expression using the try-except before formatting.

Answer: Yes, but there are downsides:

  • There can be a lot of expressions in one line and even simple ones may fail, e.g. because a variable is not defined. When evaluating each expression individually, the line count rises or a helper is needed (interesting example here). Both reduce the readability.
  • When the whole print/log statement is inside a try-except, it outputs all or nothing.

Objection 2: If you need it, your approach to logging is flawed. You should log otherwise, e.g. you should log one value at time, etc.

Answer: My real-world experience with problems related to external systems that are sometimes (albeit rarely) behaving in an unexpected or undocumented way led me to re-visit this proposal. Practicality beats purity.

1 Like