[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
implementation.

Eric.



More information about the Python-Dev mailing list