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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
