On Wed, Oct 27, 2010 at 12:36, Antoine Pitrou wrote:
> On Wed, 27 Oct 2010 10:13:12 +0800
> Kristján Valur Jónsson wrote:
>> Although 2.7 has the new buffer interface and memoryview
>> objects, these are widely not accepted in the built in modules.
>
> That's true, and slightly unfortunate. It co
2010/11/1 Kristján Valur Jónsson :
> Ah, yes. There are, in my case. (why do I always seem to be doing stuff
> that is different from what you all are doing:)
I would guess that most of us aren't writing MMOs for a living. Gamers
seem to be a particularly demanding breed of user :)
Cheers,
Nic
ity: let memoryview[:] return self,
since the object is immutable, I believe.
K
> -Original Message-
> From: "Martin v. Löwis" [mailto:mar...@v.loewis.de]
> Sent: 1. nóvember 2010 14:22
> To: Kristján Valur Jónsson
> Cc: python-dev@python.org
> S
Stefan Behnel, 01.11.2010 09:45:
If slice object creation bothers you here, it might be worth using a
free list in PySlice_New() instead of creating new slice objects on
request.
[...]
You can take a look at how it's done in tupleoject.c if you want to
provide a patch.
Hmm, that's actually a pa
hon-dev@python.org
> Subject: Re: [Python-Dev] new buffer in python2.7
>
> Kristján Valur Jónsson, 27.10.2010 16:28:
> > Notice how a Slice object is generated. Then a PyObject_GetItem()
> is
> > done. The salient code path is from apply_slice(). A slice object
> must
Kristján Valur Jónsson, 27.10.2010 16:28:
Notice how a Slice object is generated. Then a PyObject_GetItem() is
done. The salient code path is from apply_slice(). A slice object must
be constructed and destroyed.
If slice object creation bothers you here, it might be worth using a free
list
Kristján Valur Jónsson, 27.10.2010 16:32:
Sorry, here the tables properly formatted:
Certainly looked better on your first try.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
>> def read_and_unpack(stream, format):
>> data = stream.read(struct.calcsize(format))
>> return struct.unpack(format, data)
>>
>>> Otherwise, I'm +1 on your suggestion, avoiding copying is a good
>>> thing.
>>
>> I believe my function also doesn't involve any unnecessary copies.
> You just
: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
"Martin v. Löwis"
Sent: Friday, October 29, 2010 18:15
To: python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7
That is easy to achiev
> Actually I would like code like
> s = socket()
> ...
> header = struct.unpack("i", s)
>
> In other words, struct should interact with files/streams directly, instead
> of
> requiring me to first read a chunk who's size I manually have to determine
> etc.
That is easy to achieve using t
python.org] On Behalf Of
Antoine Pitrou
Sent: Wednesday, October 27, 2010 20:15
To: python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7
On Wed, 27 Oct 2010 20:00:10 +0800
Kristján Valur Jónsson mailto:krist...@ccpgames.com>>
wrote:
> Calling getbuffer on a bytearra
-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7
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.
Ca
unces+kristjan=ccpgames@python.org] On Behalf Of
Kristján Valur Jónsson
Sent: Wednesday, October 27, 2010 20:00
To: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] new buffer in python2.7
Ah, well in 2.7 you don't have the luxury of a bytes object. A str() would be
simi
On Wed, 27 Oct 2010 20:00:10 +0800
Kristján Valur Jónsson wrote:
> 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.
It *is* cheap. It's just that copying a short slice is dirt cheap as
well.
Of course, it y
ednesday, October 27, 2010 19:16
To: python-dev@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'*1" "x[:100]"
> > 1000 loops, best of 3: 0.134 usec per
> >Here are micro-benchmarks under 3.2:
>
> > $ ./python -m timeit -s "x = b'x'*1" "x[:100]"
> > 1000 loops, best of 3: 0.134 usec per loop
> > $ ./python -m timeit -s "x = memoryview(b'x'*1)" "x[:100]"
> > 1000 loops, best of 3: 0.151 usec per loop
>
> That's weird. The greedy
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Antoine Pitrou
Sent: Wednesday, October 27, 2010 18:36
>Here are micro-benchmarks under 3.2:
> $ ./python -m timeit -s "x = b'x'*1000
On Wed, 27 Oct 2010 10:13:12 +0800
Kristján Valur Jónsson wrote:
> Although 2.7 has the new buffer interface and memoryview
> objects, these are widely not accepted in the built in modules.
That's true, and slightly unfortunate. It could be a reason for
switching to 3.1/3.2 :-)
> IMHO this is un
On Wednesday 27 October 2010, Kristján Valur Jónsson wrote:
> Although 2.7 has the new buffer interface and memoryview objects, these are
> widely not accepted in the built in modules. Examples are the structmodule,
> some of the socketmodule apis, structmodule, etc.
>
> IMHO this is unfortunate.
Not forgetggin the StringI object in cStringIO.
IMHO, not accepting buffers by these objects can be consided a bug, that needs
fixing.
K
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Kristján Valur Jónsson
Sen
20 matches
Mail list logo
