<p dir="ltr"><br>
On 17 Jan 2014 18:03, "Eric Snow" <<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>> 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</p>
<p dir="ltr">Please don't make me learn the limitations of a new mini language without a really good reason.</p>
<p dir="ltr">For the sake of argument, assume we have a Python 3.5 with bytes.__mod__ restored roughly as described in PEP 461. *Given* that feature set, what is the rationale for *adding* bytes.format? What new capabilities will it provide that aren't already covered by printf-style interpolation directly to bytes or text formatting followed by encoding the result?</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -eric<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">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>