Fredrik Lundh wrote:
> the "right solution" for things like this is an *API* that lets you do
> things like:
>
> view = object.acquire_view(region, supported formats)
And how do you describe the "supported formats"?
That's where Travis's proposal comes in, as far
as I can see.
--
Greg
__
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
Fredrik Lundh wrote:
> Chris Barker wrote:
>
>
>>While /F suggested we get off the PIL bandwagon
>
>
> I suggest we drop the obsession with pointers to memory areas that are
> supposed to have a specific format; modern data access API:s don't work
> that way for good reasons, so I don't see w
Chris Barker wrote:
> While /F suggested we get off the PIL bandwagon
I suggest we drop the obsession with pointers to memory areas that are
supposed to have a specific format; modern data access API:s don't work
that way for good reasons, so I don't see why Python should grow a
standard based
Martin v. Löwis v.loewis.de> writes:
> Can you please give examples for real-world applications of this
> interface, preferably examples involving multiple
> independently-developed libraries?
OK -- here's one I haven't seen in this thread yet:
wxPython has a lot code to translate between vario
Fredrik Lundh wrote:
> Terry Reedy wrote:
>
>> I believe that at present PyGame can only work with external images that it
>> is programmed to know how to import. My guess is that if image source
>> program X (such as PIL) described its data layout in a way that NumPy could
>> read and act on,
Terry Reedy wrote:
> I believe that at present PyGame can only work with external images that it
> is programmed to know how to import. My guess is that if image source
> program X (such as PIL) described its data layout in a way that NumPy could
> read and act on, the import/copy step could b
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Paul Moore (IIRC) gave the example of equalising the green values
> and maximizing the red values in a PIL image by passing it to NumPy:
> Is that a realistic (even though not-yet real-world) example? If
> so, what
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>Several extensions to Python utilize the buffer protocol to share
>>the location of a data-buffer that is really an N-dimensional
>>array. However, there is no standard way to exchange the
>>additional N-dimensional array in
On 10/30/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:> > Attached is my PEP for extending the buffer protocol to allow array data> to be shared.
You might want to reference this thread (http://mail.python.org/pipermail/python-3000/2006-August/003309.html) as Guido mentions that extending the b
Travis E. Oliphant schrieb:
> Several extensions to Python utilize the buffer protocol to share
> the location of a data-buffer that is really an N-dimensional
> array. However, there is no standard way to exchange the
> additional N-dimensional array information so that the data-b
Attached is my PEP for extending the buffer protocol to allow array data
to be shared.
PEP:
Title: Extending the buffer protocol to include the array interface
Version: $Revision: $
Last-Modified: $Date: $
Author: Travis Oliphant <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Creat
12 matches
Mail list logo
