Carl Banks wrote:
> Tr
> ITSM that we are using the word "view" very differently. Consider
> this example:
>
> A = zeros((100,100))
> B = A.transpose()
You are thinking of NumPy's particular use case. I'm thinking of a
generic use case. So, yes I'm using the word view in two different
cont
Greg Ewing wrote:
> But since the NumPy object has to know about the provider,
> it can simply pass the release call on to it if appropriate.
> I don't see how this case necessitates making the release call
> on a different object.
>
> I'm -1 on involving any other objects or returning object
> re
Travis Oliphant wrote:
> Carl Banks wrote:
>
>> Tr
>> ITSM that we are using the word "view" very differently. Consider
>> this example:
>>
>> A = zeros((100,100))
>> B = A.transpose()
>
>
> You are thinking of NumPy's particular use case. I'm thinking of a
> generic use case. So, yes I'm u
Carl Banks wrote:
> It's easy to see possible use cases for returning a different object. A
> hypothetical future incarnation of NumPy might shift the
> responsibility of managing buffers from NumPy array object to a hidden
> raw buffer object. In this scenario, the NumPy object is the expo
Travis Oliphant wrote:
> Carl Banks wrote:
>> We're done. Return pointer.
>
> Thank you for this detailed example. I will have to parse it in more
> depth but I think I can see what you are suggesting.
>
>> First, I'm not sure why getbuffer needs to return a view object.
>
> The view object
Carl Banks wrote:
> We're done. Return pointer.
Thank you for this detailed example. I will have to parse it in more
depth but I think I can see what you are suggesting.
>
> First, I'm not sure why getbuffer needs to return a view object.
The view object in your case would just be the Image
(cc'ing back to Python-dev; the original reply was intended for it by I
had an email malfunction.)
Travis Oliphant wrote:
>Carl Banks wrote:
>> 3. Allow getbuffer to return an array of "derefence offsets", one for
>> each dimension. For a given dimension i, if derefoff[i] is
>> nonnegative, i
I have developed a split vector type that implements the buffer protocol at
http://scintilla.sourceforge.net/splitvector-1.0.zip
It acts as a mutable string implementing most of the sequence
protocol as well as the buffer protocol. splitvector.SplitVector('c')
creates a vector containing 8 b
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>I'm talking about arrays of pointers to other arrays:
>>
>>i.e. if somebody defined in C
>>
>>float B[10][20]
>>
>>then B would B an array of pointers to arrays of floats.
>
>
> No, it wouldn't, it would be a contiguously stored
> 2-dimensional a
Travis Oliphant wrote:
> I'm talking about arrays of pointers to other arrays:
>
> i.e. if somebody defined in C
>
> float B[10][20]
>
> then B would B an array of pointers to arrays of floats.
No, it wouldn't, it would be a contiguously stored
2-dimensional array of floats. An array of pointe
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>
>>The question is should we eliminate the possibility of sharing memory
>>for objects that store data basically as "arrays" of arrays (i.e. true
>>C-style arrays).
>
>
> Can you clarify what you mean by this? Are you talking
> about an array of p
Greg Ewing:
> So an array-of-pointers interface wouldn't be a direct
> substitute for the existing multi-segment buffer
> interface.
Providing an array of (pointer,length) wouldn't be too much extra
work for a split vector implementation.
Guido van Rossum:
> But there's always a call to remo
Travis Oliphant wrote:
> The question is should we eliminate the possibility of sharing memory
> for objects that store data basically as "arrays" of arrays (i.e. true
> C-style arrays).
Can you clarify what you mean by this? Are you talking
about an array of pointers to other arrays? (This is
Neil Hodgson wrote:
>I think one of the motivations for discontiguous segments was for
> split buffers which are commonly used in text editors.
Note that this is different from the case of an array
of pointers to arrays, which is a multi-dimensional
array structure, whereas a split buffer is
On 3/21/07, Neil Hodgson <[EMAIL PROTECTED]> wrote:
> Travis Oliphant:
>
> > 3) information about discontiguous memory segments
> >
> >
> > Number 3 is where I could use feedback --- especially from PIL users and
> > developers. Strides are a common way to think about a possibly
> > discontiguous
Travis Oliphant:
> 3) information about discontiguous memory segments
>
>
> Number 3 is where I could use feedback --- especially from PIL users and
> developers. Strides are a common way to think about a possibly
> discontiguous chunk of memory (which appear in NumPy when you select a
> sub-reg
Attached is the PEP.
:PEP: XXX
:Title: Revising the buffer protocol
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Travis Oliphant <[EMAIL PROTECTED]>
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 28-Aug-2006
:Python-Version: 3000
Abstract
This PE
I'm soliciting feedback on my extended buffer protocol that I am
proposing for inclusion in Python 3000. As soon as the Python 3.0
implementation is complete, I plan to back-port the result to Python
2.6, therefore, I think there may be some interest on this list.
Basically, the extended buff
18 matches
Mail list logo
