[Python-Dev] PEP 460 reboot

MRAB python at mrabarnett.plus.com
Tue Jan 14 22:34:35 CET 2014


On 2014-01-14 20:54, Guido van Rossum wrote:
> On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 01/14/2014 10:52 AM, Guido van Rossum wrote:
>>>
>>> Which reminds me. Quite a few people have spoken out in favor of loud
>>> failures rather than silent "wrong" output. But I think that in the
>>> specific context of formatting output, there is a long and IMO good
>>> tradition of producing (slightly) wrong output in favor of more strict
>>> behavior. Consider for example what to do when a number doesn't fit in
>>> the given width. Would you rather raise an exception, truncate the
>>> value, or mess up the formatting?
>>
>> One more data point to consider:  When the binary format has strict rules on
>> how much space a data-point is allowed, then failure is the only appropriate
>> option.
>
> Yes, that's how the struct module works.
>
>> In Py2, because '%15s' can actually take 17 characters, I have to use '%15s'
>> % data_value[:15] everywhere.
>
> Wow. I thought there would be some combination using %.15s but I can't
> get that to work. :-(
>
I've not sure what you mean here:

Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit 
(AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import string
 >>> '%.15s' % string.letters
'abcdefghijklmno'
 >>> len(_)
15

>> I'm not suggesting we change how that portion works, as it would then be, I
>> think, too different from both Py2 behavior as well as current str behavior,
>> but likewise adding in single quotes would of no help to me.  Loud failure
>> so I can easily see where I forgot the .encode() would be much more helpful.
>
> If we go with a more restricted version this makes sense indeed. The
> single quotes seemed unavoidable when I was trying (like several other
> proposals) to have a format code that works for all types. I think
> we're rightly giving up on that now.
>
> (I should review PEP 461, but I don't have time yet.)
>



More information about the Python-Dev mailing list