[Python-Dev] new buffer in python2.7
Kristján Valur Jónsson
kristjan at ccpgames.com
Wed Oct 27 14:00:10 CEST 2010
Ah, well in 2.7 you don't have the luxury of a bytes object. A str() would be similar in 2.7
Anyway, isn't the "bytes" object immutable? In that case, it is not a useful target for a sock.recv_into() call.
Calling getbuffer on a bytearray or a bytes object should be really cheap, so I still don't accept this as a matter of fact situation.
Btw, going to 3.2 isn't a real option for us any time soon. A lot of companies probably find themselves in a similar situation. This is why I spend so much effort applying some love to 2.7. Most of the stuff I locally do to 2.7 I then contribute to python as 3.2 patches. Someday they'll get backported, no doubt :)
From: python-dev-bounces+kristjan=ccpgames.com at python.org [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Antoine Pitrou
Sent: Wednesday, October 27, 2010 19:16
To: python-dev at python.org
Subject: Re: [Python-Dev] new buffer in python2.7
> >Here are micro-benchmarks under 3.2:
> > $ ./python -m timeit -s "x = b'x'*10000" "x[:100]"
> > 10000000 loops, best of 3: 0.134 usec per loop $ ./python -m timeit
> > -s "x = memoryview(b'x'*10000)" "x[:100]"
> > 10000000 loops, best of 3: 0.151 usec per loop
> That's weird. The greedy slice needs two memory allocations. One for
> the ByteArray object itself, one for its cargo. In total, more that
> 100 bytes. In contrast, creating the MemoryView object requires only
> one allocation of a few dozen bytes.
It's not a bytearray object, it's a bytes object. It requires only a single allocation since the data is allocated inline.
The memoryview object must also call getbuffer() again on the original object.
Python-Dev mailing list
Python-Dev at python.org
More information about the Python-Dev