RetroSearch Browse

Fri Jan 10 23:58:15 CET 2014 · https://mail.python.org/pipermail/python-dev/2014-January/131167.html

On 01/10/2014 02:42 PM, Antoine Pitrou wrote:
> On Fri, 10 Jan 2014 17:33:57 -0500
> "Eric V. Smith" <eric at trueblade.com> wrote:
>> On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
>>> On Fri, 10 Jan 2014 12:56:19 -0500
>>> "Eric V. Smith" <eric at trueblade.com> wrote:
>>>>
>>>> I agree. I don't see any reason to exclude int and float. See Guido's
>>>> messages http://bugs.python.org/issue3982#msg180423 and
>>>> http://bugs.python.org/issue3982#msg180430 for some justification and
>>>> discussion.
>>>
>>> If you are representing int and float, you're really formatting a text
>>> message, not bytes. Basically if you allow the formatting of int and
>>> float instances, there's no reason not to allow the formatting of
>>> arbitrary objects through __str__. It doesn't make sense to
>>> special-case those two types and nothing else.
>>
>> It might not for .format(), but I'm not convinced. But for %-formatting,
>> str is already special-cased for these types.
>
> That's not what I'm saying. str.__mod__ is able to represent all kinds
> of types through %s and calling __str__. It doesn't make sense for
> bytes.__mod__ to only support int and float. Why only them?

Because embedding the ASCII equivalent of ints and floats in byte streams is a common operation?

--
~Ethan~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2014-January/131167.html below:

[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5