[issue3982] support .format for bytes

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

On Jan 22, 2013, at 11:27 PM, Antoine Pitrou <report at bugs.python.org> wrote:

> Antoine Pitrou added the comment:
> 
> The "ASCII superset commands" part is clearly separated from the "binary
> data" part. Your own LineReceiver is able to switch between "raw mode"
> and "line mode"; one is text and the other is binary.

This is incorrect.  "Lines" are just CRLF (0x0D0A) separated chunks of data.  For example, SMTP is always in line-mode, but messages ("data lines") may contain arbitrary 8-bit data.

> This is a non-sequitur. You can fully well (...)
> So, yes, it is reasonably possible, and it even makes sense.

I concede it is possible to implement what you're talking about, but it still requires encoding things which are potentially 8-bit data.  Yes, there are many corners of protocols where said data looks like text, but it is an optical illusion.

>> even disregarding compatibility with a 2.x codebase, b''.join() and
>> b'' + b'' and (''.format()).encode('charmap') are all slower _and_
>> more awkward than simply b''.format() or b''%.
> 
> How can existing constructions be slower than non-existing constructions
> that don't have performance numbers at all?

Sorry, "in 2.x" :).

> Besides, if b''.join() is too slow, it deserves to be improved. Or
> perhaps you should try bytearray instead, or even io.BytesIO.

As others have noted, b''.join is *not* slower than b''.format for simply assembling strings; b''.join is indeed faster at that and I didn't mean to say it wasn't.  The performance improvement shows up when you are assembling complex messages that contain a smattering of ints, floats, and other chunks of bytes; mostly in that you can avoid a bunch of python code execution and python function calls when formatting those values.  The trouble with cooking up an example of this is that it starts to involve a bunch of additional code complexity and it requires careful framing to make sure the other complexity isn't what's getting in the way.  I will try to come up with one, maybe doing so will prove even this contention wrong.

But, the main issue here is expressiveness, not performance.

----------

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