Message180489
On Jan 22, 2013, at 11:27 PM, Antoine Pitrou <report@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. |
|
Date |
User |
Action |
Args |
2013-01-23 18:57:51 | glyph | set | recipients:
+ 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:51 | glyph | link | issue3982 messages |
2013-01-23 18:57:51 | glyph | create | |
|