[Python-ideas] Binary f-strings

[Eric V. Smith]

> On Oct 7, 2015, at 2:01 PM, Eric V. Smith <eric at trueblade.com> wrote:
> 
>> On 10/07/2015 01:58 PM, Guido van Rossum wrote:
>> Of course that would still leave the door open for struct.pack support
>> (maybe recognized by having the string start with <,=, > or @). Pro:
>> everybody who currently uses struct.pack will love it. Con: the
>> struct.pack mini-language is pretty inscrutable if you don't already
>> know it. (And no, I don't propose to invent a different mini-language --
>> it's just easier to figure out where to find docs for this when the code
>> explicitly imports the struct module.)
> 
> Right. I think Steve Dower's idea of :p switching to struct.pack mode is
> reasonable. But as Nick says, we don't need to add it on day 1.

Make that "!p". 

Eric. 

> 
> Eric.
> 
>> 
>> On Wed, Oct 7, 2015 at 10:53 AM, Eric V. Smith <eric at trueblade.com
>> <mailto:eric at trueblade.com>> wrote:
>> 
>>>    On 10/07/2015 12:25 PM, Guido van Rossum wrote:
>>> I think bf'...' should be compared to b'...' % rather than to f'...'.
>>> IOW bf'...' is to f'...' as b'...'% is to '...'%.
>> 
>>    I'm leaning this way, at least in the sense of "there's a fixed number
>>    of known types supported, and there's no extensible protocol involved.
>> 
>>    Eric.
>> 
>>> 
>>> On Wed, Oct 7, 2015 at 5:34 AM, Andrew Barnert <abarnert at yahoo.com <mailto:abarnert at yahoo.com>
>>> <mailto:abarnert at yahoo.com <mailto:abarnert at yahoo.com>>> wrote:
>>> 
>>>    On Oct 7, 2015, at 04:35, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>
>>>    <mailto:ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>>> wrote:
>>>> 
>>>>> On 4 October 2015 at 08:25, Andrew Barnert
>>    <abarnert at yahoo.com <mailto:abarnert at yahoo.com>
>>    <mailto:abarnert at yahoo.com <mailto:abarnert at yahoo.com>>> wrote:
>>>>> Nick's suggestion of having it do %-formatting makes sense.
>>    Yes, it means
>>>>> that {count:03} is an error and you need '{count:03d}',
>>    which is
>>>>> inconsistent with f-strings. But that seems like a much
>>    less serious problem
>>>>> than bytes formatting not being able to handle bytes.
>>>> 
>>>> Exactly, if someone is mistakenly thinking
>>>> bf"{header}{content}{footer}" is equivalent to
>>>> f"{header}{content}{footer}".encode(), they're likely to get
>>    immediate
>>>> noisy errors when they start trying to format fields.
>>> 
>>>    Except that multiple people in this thread are saying that'd
>>    exactly
>>>    what it should mean (which I think is a very bad idea).
>>> 
>>>> The parallel I'd attempt to draw is that:
>>>> 
>>>>   f"{header}{content}{footer}" is to
>>    "{}{}{}".format(header, content, footer)
>>>> 
>>>> as:
>>>> 
>>>>   bf"{header:b}{content:b}{footer:b}" would be to b"%b%b%b" %
>>>> (header, content, footer)
>>>> 
>>>> To make the behaviour clearer in the latter case, it may be
>>    reasonable
>>>> to *require* an explicit field format code, since that
>>    corresponds
>>>> more closely to the mandatory field format codes in
>>    mod-formatting.
>>> 
>>>    Are you suggestive that if a format specifier is given, it must
>>>    include the format code (which seems perfectly reasonable to
>>>    me--guessing that :3 means %3b is likely to be wrong more
>>    often than
>>>    it's right…), or that a format specifier must always be given,
>>    with
>>>    no default to :b (which seems more obtrusive and solves less of a
>>>    problem).
>>> 
>>> 
>>> 
>>> 
>>> --
>>> --Guido van Rossum (python.org/~guido <http://python.org/~guido>
>>    <http://python.org/~guido>)
>>> 
>>> 
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org <mailto:Python-ideas at python.org>
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>> 
>> 
>> 
>> 
>> -- 
>> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/