%-style formatting method

[timhoffm (Tim Hoffmann)]

@pf_moore

tl;dr; It’s not likely to go away, but there’s little reason to spend time improving it.

YMMV, but you probably need to get some support from a core dev if you expect any of this to go anywhere. And I think that will be hard.

Thanks for the reminder. I’m trying to lay out a differentiated case for the benefits of a .pformat() method. It’s in between “leave the quirky %-operator in place as a first class language feature” and deprecating it.

An annoying aspect with the %-operator is that the docs do not clearly discourage it (I’m not calling for deprecation or breaking existing code). I would like to see a clear statement “do not use the %-formatting operator for new code”. But instead, there’s a dance of words with “new format”/“old format” (link), “quirks”, “may help avoid errors”, “Each of these alternatives provides their own trade-offs and benefits of simplicity, flexibility, and/or extensibility.” (link). I assume this is because one did not dare to steer people completely away from %-placeholders because there are still a few use cases where people prefer %-placeholders (see below). IMHO clearly discouraging the %-operator would be a win for the language. If that can be done without addtions to the language, great. If not, a .pformat() method may be the missing bit to convince everybody that there is no reason to use the %-operator in any new code.

@pf_moore

Adding new features, like the proposed .pformat method, is a lot easier. But the “people don’t use %-formatting any more” arguments do apply here. The benefits of adding extra features to help people using a formatting method that’s not the first choice for newer code are likely to be very small, so justifying the maintenance cost of adding those features is quite hard.

“people don’t use %-formatting any more” is generalizing a bit too much. While it’s not the first choice for the majority of use cases, there are still some cases where people still

prefer %-placeholders for new code, as expressed in this thread and Deprecate str % format operator. It’s a nuissance they then have to use the quirky %-operator.

I may not understand the full maintenance implications for the concrete case, but I would have guessed that the added code is basically the C equivalent of

def pformat(self, *args, **kwargs):
    if args and kwargs:
        raise TypeError(
            "'pformat' does not simultaneously accept positional and keyword arguments"
        )
   if args:
        return self % args
   else:
        return self % kwargs

so it’s not too much or too complicated. Also, it’s unlikely that this code will need to be modified in the future. I therefore naively assumed the maintenance cost is small.