<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</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">On 01/15/2014 06:45 AM, Brett Cannon wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote>
<br></div>
It may work like this under the hood, but it's an implementation detail.</blockquote><div><br></div><div>I'm arguing it's not an implementation detail but a definition of how bytes.format() would work.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Since the numeric format codes will call int, index, or float on the object (to handle subclasses),</blockquote>

<div><br></div><div>But that's **only** because the numeric types choose to as part of their __format__() implementation; it is not inherent to str.format().</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 we could then call __format__ on the resulting int or float to do the heavy lifting;</blockquote><div><br></div><div>It's not just the heavy lifting; it does **all** the lifting for format specifications.</div><div>
 </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but since __format__ on anything else would never be called I don't want to give that impression.<div class="im">
<br>
</div></blockquote><div><br></div><div>Fine, if you're worried about bytes.format() overstepping by implicitly calling str.encode() on the return value of __format__() then you will need __bytes__format__() to get equivalent support.</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"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br></div>
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.  ;)<div class="HOEnZb"><div class="h5">

<br>
______________________________<u></u>_________________<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/<u></u>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/<u></u>mailman/options/python-dev/<u></u>brett%40python.org</a><br>
</div></div></blockquote></div><br></div></div>