[Python-Dev] PEP 460 reboot

Terry Reedy tjreedy at udel.edu
Tue Jan 14 01:51:48 CET 2014

On 1/13/2014 3:13 PM, Guido van Rossum wrote:
> On Mon, Jan 13, 2014 at 12:02 PM, Brett Cannon <brett at python.org> wrote:
>> On Mon, Jan 13, 2014 at 2:51 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>> I personally would not add 'bytes % whatever'.
>> Personally, neither would I; just focus on bytes.format() and let % operator
>> on strings slowly go away.
> Well, % has some very strong arguments in its favor still -- for

If I shift from a 'personal' to a 'BDFL' viewpoint, I have to agree.

> example, the sheer amount of code that currently uses it, the fact
> that it's as close as we get to a cross-language standard, and the

This much I know.

> fact that nobody wants to tackle its use in the logging module (since
> logger objects are often shared between packages that don't know about
> each other).

This I did not know.

> Anyway, the % or .format() issue seems completely orthogonal to the
> issues that get people riled up (which are mostly about whether using
> either implies some kind of ASCII compatibility).

A possibly important difference between '%s' and '{:s}' is that the 's' 
is required in the former and optional in the latter. So in 
byteformat(), b'{:s}' continues to format a string (as encoded bytes) 
while '{:}' 'formats' a byte without having to invent a new code that 
does not exist in 2.7. That particular solution to "does 's' mean bytes 
or string" does not work for % formatting. (And that lack, in turn, is 
part of what lay behind the inclination expressed above.)

For % formatting, I would be inclined to start with 'what does mecurial 
need?' or even 'does anything even really work for hg?'. Hg is part of 
our development ecosystem, and we have an hg rep who expressed a desire 
to experiment.


More information about the Python-Dev mailing list