Nick Coghlan writes:
To me, the defining feature of str.format() over str.__mod__() is the ability for types to provide their own __format__ methods,
Ah, so you object to the _spelling_, not the requested functionality. (At least, not all of it.) All is clear now! OK, I retract my suggestion, but I'll let you beat up on anybody who dredges it up in the future. Specifically, I think that calling it "bytes.format" (a) is discoverable and (b) it is not obvious to me that __format_bytes__ functionality for arbitrary types is a bad thing, although I personally have no use case and am unlikely to catch one for a while (thus at most I'm now -0, and could easily be persuaded to lower that).
bytes interpolation also needs to address encoding issues for anything that isn't already a byte sequence.
Sure, but my proposal here still stands: whatever the API is, and whatever types it supports, the assumption is that interpolation uses the conventional ASCII representation for the given type (and for interpolations implemented in stdlib there had better be universal agreement on what that convention is).