[Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Terry Reedy tjreedy at udel.edu
Fri Jan 17 21:56:07 CET 2014

Responding to two posts at once, as I consider them

On 1/17/2014 11:00 AM, Brett Cannon wrote:

> I would rephrase it to "switch to %-formatting for bytes usage for their
> common code base". If they are working with actual text then using
> str.format() still works (and is actually nicer to use IMO). It actually
> might make the str/bytes relationship even clearer, especially if we
> start to promote that str.format() is for text and %-formatting is for
> bytes.

Good idea, I think: printf % formatting was invented for formatting 
ascii text in bytestrings as it was being output (although sprintf 
allowed not-output). In retrospect, I think we should have introduced 
unicode.format when unicode was introduced in 2.0 and perhap never have 
had unicode % formatting. Or we should have dropped str % instead of 
bytes % in 3.0.

On 1/17/2014 12:13 PM, Eric V. Smith wrote:
 > But if we think that %-formatting is neanderthal and will get dropped 
 > in the Python 4000 timeframe (that is, someday in the far future),

Some people, such as Martin Loewis, have a different opinion of 
%-formatting and will fight deprecating it *ever*. (I suspect that 
%-format opinions are influenced by one's current relation to C.)

 > then I think we should have some advice to give to people who are
 > writing new 3.x code for the non-porting use-cases addressed by the
 > PEP. I'm specifically thinking of new code that wants to format some 
 > bytes for an on-the-wire ascii-like protocol.

If we add %-formatting back in 3.5 for its original purpose, formatting 
ascii in bytes for output, I think we should drop the idea of later 
deprecating it (a few releases later) for that purpose. I think the PEP 
should even say so, that bytes % will remain indefinitely even if str % 
were to be dropped in favor of str.format.

I would consider dropping unicode(now string).__mod__ in favor of 
.format to still be an eventual option, especially if someone were to 
write a converter.

Terry Jan Reedy

More information about the Python-Dev mailing list