Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:27 PM, Antoine Pitrou <[email protected]> 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 <[email protected]>
<http://bugs.python.org/issue3982>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
