[issue3982] support .format for bytes

[Derek Wilson]

Derek Wilson added the comment:

First off, +1 for this feature. It's not just for twisted, but anyone doing anything with binary data (storage, compression, encryption and networking for me) with python since 2.6 will very likely have been using .format for building messages. I know I have and obviously others have been doing so as well.

The advantages of .format to me are:

* compatible with 2.6 (porting and single code base support easier)
* ease of composition (the format langauge makes it easy to build complex data structures out of bytes)
* readability (named fields make complex formats obvious)
* consistency (manipulating a block of bytes or characters can be done in a similar way)

Specific comments on the patch supplied by terry.reedy:

* it doesn't support named fields
* it doesn't handle padding
* it doesn't handle nested formats (like '{0:{1}>{2}}'.format(data,pad_char,pad_width)
* formatting byte strings with a width embedds the repr of the byte string ( bf(b'{:>10}', [b'test']) == b"   b'test'" )

Really this isn't a good way to solve the problem.

Has a PEP been created for this? If not how can I help make that happen?

Including this in 3.5 would be so helpful for us low level systems programmers out there who have lots of code using .format for binary interfaces in python 2.6/2.7 already.

Also, not to add to derailment, but if we're adding a .format for python3 bytes it would be great if .format could pad with the null byte ('\0') which it currently converts to spaces internally (which is strange). Since this unexpected conversion is bad (so padding with null doesn't happen in python2) its more like a bug fix... actually - maybe that's a separate bug to file on the current .format for text...

----------
nosy: +underrun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________