[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 :)


-----Original Message-----
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
Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com

More information about the Python-Dev mailing list