[Python-Dev] PEP 461 - Adding % and {} formatting to bytes (original) (raw)

Eric V. Smith eric at trueblade.com
Fri Jan 17 16:50:20 CET 2014

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" <ericsnowcurrently at gmail.com_ _<mailto:ericsnowcurrently at gmail.com>> wrote:

On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <eric at trueblade.com_ _<mailto:eric at 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 formatascii (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 formatascii 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 formatascii protocol. We might want to also add a formatascii() 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.

More information about the Python-Dev mailing list