<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 4:56 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.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="im"><p dir="ltr"><br>
On 16 Jan 2014 17:53, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
><br>
> On 01/15/2014 06:45 AM, Brett Cannon wrote:<br>
>><br>
>><br>
>> This is why I have argued that if you specify it as "if there is a format spec specified, then the return value from<br>
>> calling __format__() will have str.decode('ascii', 'strict') called on it" you get the support for the various<br>
>> number-specific format specs for free.<br>
><br>
><br>
> It may work like this under the hood, but it's an implementation detail.  Since the numeric format codes will call int, index, or float on the object (to handle subclasses), we could then call __format__ on the resulting int or float to do the heavy lifting; but since __format__ on anything else would never be called I don't want to give that impression.</p>



</div><p dir="ltr">I have a different proposal: let's *just* add mod formatting to bytes, and leave the extensible formatting system as a text only operation.</p>
<p dir="ltr">We don't really care if bytes supports that method for version compatibility purposes, and the deliberate flexibility of the design makes it hard to translate into the binary domain.</p>
<p dir="ltr">So let's just not provide that - let's accept that, for the binary domain, printf style formatting is just a better fit for the job :)</p></blockquote><div><br></div><div>Or PEP 460 for bytes.format() and PEP 461 for %.</div>

<div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr"></p><div class="im">><br>
><br>
>> It also means if you pass in a string that you just want the strict ASCII bytes<br>
>> of then you can get it with {:s}.<br>
><br>
><br>
> This isn't going to happen.  If the user wants a string to be in the byte stream, it has to either be a bytes literal or explicitly encoded [1].<br>
><br>
> --<br>
> ~Ethan~<br>
><br>
> [1] Apologies if this has already been answered.  I wanted to make sure I responded to all the ideas/objects, and I may have responded more than once to some.  It's been a long few threads.  ;)<br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br></div>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
<p></p>
<br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
<br></blockquote></div><br></div></div>