On 01/17/2014 10:24 AM, Eric V. Smith wrote:
> On 01/17/2014 10:15 AM, Mark Lawrence wrote:
>> On 17/01/2014 14:50, Eric V. Smith wrote:
>>> On 01/17/2014 07:34 AM, Eric V. Smith wrote:
>>>> On 1/17/2014 6:42 AM, Nick Coghlan wrote:
>>>>>
>>>>> On 17 Jan 2014 18:03, "Eric Snow" <ericsnowcurren...@gmail.com
>>>>> <mailto:ericsnowcurren...@gmail.com>> wrote:
>>>>>>
>>>>>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <e...@trueblade.com
>>>>> <mailto:e...@trueblade.com>> wrote:
>>>>>>> For the first iteration of bytes.format(), I think we should just
>>>>>>> support the exact types of int, float, and bytes. It will call the
>>>>>>> type's__format__ (with the object as "self") and encode the result to
>>>>>>> ASCII. For the stated use case of 2.x compatibility, I suspect
>>>>>>> this will
>>>>>>> cover > 90% of the uses in real code. If we find there are cases
>>>>>>> where
>>>>>>> real code needs additional types supported, we can consider adding
>>>>>>> __format_ascii__ (or whatever name we cook up).
>>>>>>
>>>>>> +1
>>>>>
>>>>> Please don't make me learn the limitations of a new mini language
>>>>> without a really good reason.
>>>>>
>>>>> 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?
>>>>
>>>> The only reason to add any of this, in my mind, is to ease porting of
>>>> 2.x code. If my proposal covers most of the cases of b''.format() that
>>>> exist in 2.x code that wants to move to 3.5, then I think it's worth
>>>> doing. Is there any such code that's blocked from porting by the lack of
>>>> b''.format() that supports bytes, int, and float? I don't know. I
>>>> concede that it's unlikely.
>>>>
>>>> IF this were a feature that we were going to add to 3.5 on its own
>>>> merits, I think we add __format_ascii__ and make the whole thing
>>>> extensible. Is there any new code that's blocked from being written by
>>>> missing b"".format()? I don't know that, either.
>>>
>>> Following up, I think this leaves us with 3 choices:
>>>
>>> 1. Do not implement bytes.format(). We tell any 2.x code that's written
>>> to use str.format() to switch to %-formatting for their common code base.
>>>
>>> 2. Add the simplistic version of bytes.format() that I describe above,
>>> restricted to accepting bytes, int, and float (and no subclasses). Some
>>> 2.x code will work, some will need to change to %-formatting.
>>>
>>> 3. Add bytes.format() and the __format_ascii__ protocol. We might want
>>> to also add a format_ascii() builtin, to match __format__ and format().
>>> This would require the least change to 2.x code that uses str.format()
>>> and wants to move to bytes.format(), but would require some work on the
>>> 3.x side.
For #3, hopefully this "additional work" on the 3.x side would just be
to add, to each class where you already have a custom __format__ used
for b''.format(), code like:
def __format_ascii__(self, fmt):
return self.__format__(fmt.decode()).encode('ascii')
That is, we're pushing the possibility of having to deal with an
encoding exception off to the type, instead of having it live in
bytes.format().
And to agree with Ethan: %-formatting isn't deprecated.
Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
