[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Eric V. Smith eric at trueblade.com
Fri Jan 10 18:56:19 CET 2014

On 1/10/2014 12:17 PM, Juraj Sukop wrote:
> (Sorry if this messes-up the thread order, it is meant as a reply to the
> original RFC.)
> Dear list,
> newbie here. After much hesitation I decided to put forward a use case
> which bothers me about the current proposal. Disclaimer: I happen to
> write a library which is directly influenced by this.
> As you may know, PDF operates over bytes and an integer or
> floating-point number is written down as-is, for example "100" or "1.23".
> However, the proposal drops "%d", "%f" and "%x" formats and the
> suggested workaround for writing down a number is to use
> ".encode('ascii')", which I think has two problems:
> One is that it needs to construct one additional object per formatting
> as opposed to Python 2; it is not uncommon for a PDF file to contain
> millions of numbers.
> The second problem is that, in my eyes, it is very counter-intuitive to
> require the use of str only to get formatting on bytes. Consider the
> case where a large bytes object is created out of many smaller bytes
> objects. If I wanted to format a part I had to use str instead. For example:
>     content = b''.join([
>         b'header',
>         b'some dictionary structure',
>         b'part 1 abc',
>         ('part 2 %.3f' % number).encode('ascii'),
>         b'trailer'])

I agree. I don't see any reason to exclude int and float. See Guido's
messages http://bugs.python.org/issue3982#msg180423 and
http://bugs.python.org/issue3982#msg180430 for some justification and
discussion. Since converting int and float to strings generates a very
small range of ASCII characters, ([0-9a-fx.-=], plus the uppercase
versions), what problem is introduced by allowing int and float? The
original str.format() work relied on this fact in its stringlib


More information about the Python-Dev mailing list