This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author glyph
Recipients arjennienhuis, benjamin.peterson, christian.heimes, eric.smith, exarkun, ezio.melotti, flox, glyph, gvanrossum, loewis, martin.panter, pitrou, serhiy.storchaka, terry.reedy, uau, vstinner
Date 2013-01-23.18:57:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <1358925897.3453.14.camel@localhost.localdomain>
On Jan 22, 2013, at 11:27 PM, Antoine Pitrou <> 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.
Date User Action Args
2013-01-23 18:57:51glyphsetrecipients: + glyph, gvanrossum, loewis, terry.reedy, exarkun, pitrou, vstinner, eric.smith, christian.heimes, benjamin.peterson, ezio.melotti, arjennienhuis, flox, uau, martin.panter, serhiy.storchaka
2013-01-23 18:57:51glyphlinkissue3982 messages
2013-01-23 18:57:51glyphcreate