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.
Sent: Wednesday, October 27, 2010 10:13
To: Python-Dev (python-dev@python.org)
Subject: [Python-Dev] new buffer in python2.7
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
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. For example when doign network io, you would want
code like this:
B
21 matches
Mail list logo
