<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 9:50 AM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/17/2014 07:34 AM, Eric V. Smith wrote:<br>
> On 1/17/2014 6:42 AM, Nick Coghlan wrote:<br>
>><br>
>> On 17 Jan 2014 18:03, "Eric Snow" <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a><br>
>> <mailto:<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>>> wrote:<br>
>>><br>
>>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <<a href="mailto:eric@trueblade.com">eric@trueblade.com</a><br>
>> <mailto:<a href="mailto:eric@trueblade.com">eric@trueblade.com</a>>> wrote:<br>
>>>> For the first iteration of bytes.format(), I think we should just<br>
>>>> support the exact types of int, float, and bytes. It will call the<br>
>>>> type's__format__ (with the object as "self") and encode the result to<br>
>>>> ASCII. For the stated use case of 2.x compatibility, I suspect this will<br>
>>>> cover > 90% of the uses in real code. If we find there are cases where<br>
>>>> real code needs additional types supported, we can consider adding<br>
>>>> __format_ascii__ (or whatever name we cook up).<br>
>>><br>
>>> +1<br>
>><br>
>> Please don't make me learn the limitations of a new mini language<br>
>> without a really good reason.<br>
>><br>
>> For the sake of argument, assume we have a Python 3.5 with bytes.__mod__<br>
>> restored roughly as described in PEP 461. *Given* that feature set, what<br>
>> is the rationale for *adding* bytes.format? What new capabilities will<br>
>> it provide that aren't already covered by printf-style interpolation<br>
>> directly to bytes or text formatting followed by encoding the result?<br>
><br>
> The only reason to add any of this, in my mind, is to ease porting of<br>
> 2.x code. If my proposal covers most of the cases of b''.format() that<br>
> exist in 2.x code that wants to move to 3.5, then I think it's worth<br>
> doing. Is there any such code that's blocked from porting by the lack of<br>
> b''.format() that supports bytes, int, and float? I don't know. I<br>
> concede that it's unlikely.<br>
><br>
> IF this were a feature that we were going to add to 3.5 on its own<br>
> merits, I think we add __format_ascii__ and make the whole thing<br>
> extensible. Is there any new code that's blocked from being written by<br>
> missing b"".format()? I don't know that, either.<br>
<br>
</div></div>Following up, I think this leaves us with 3 choices:<br>
<br>
1. Do not implement bytes.format(). We tell any 2.x code that's written<br>
to use str.format() to switch to %-formatting for their common code base.<br></blockquote><div><br></div><div>+1</div><div><br></div><div>I would rephrase it to "switch to %-formatting for bytes usage for their common code base". If they are working with actual text then using str.format() still works (and is actually nicer to use IMO). It actually might make the str/bytes relationship even clearer, especially if we start to promote that str.format() is for text and %-formatting is for bytes.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Add the simplistic version of bytes.format() that I describe above,<br>
restricted to accepting bytes, int, and float (and no subclasses). Some<br>
2.x code will work, some will need to change to %-formatting.<br></blockquote><div><br></div><div>-1</div><div><br></div><div>I am still not comfortable with the special-casing by type for bytes.format().</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Add bytes.format() and the __format_ascii__ protocol. We might want<br>
to also add a format_ascii() builtin, to match __format__ and format().<br>
This would require the least change to 2.x code that uses str.format()<br>
and wants to move to bytes.format(), but would require some work on the<br>
3.x side.<br></blockquote><div><br></div><div>+0</div><div><br></div><div>Would allow for easy porting and it's general enough, but I don't know if working with bytes really requires this much beyond supporting the porting story.</div>

<div><br></div><div>I'm still +1 on PEP 460 for bytes.format() as a nice way to simplify basic bytes usage in Python 3, but if that's not accepted then I say just drop bytes.format() entirely and let %-formatting be the way people do Python 2/3 bytes work (if they are not willing to build it up from scratch like they already can do).</div>

<div><br></div><div>-Brett</div></div></div></div>