Here's another idea, to allow multiple views of the same
buffer with different shape/stride info to coexist, but
without extra provider objects or refcount weirdness.
Also it avoids using calls with a brazillion arguments.
struct bufferinfo {
void **buf;
Py_ssize_t *len;
int *wri
Travis Oliphant wrote:
> > Here is my updated PEP which incorporates several parts of the
> > discussions we have been having.
It looks pretty good.
However, I'm still having trouble seeing what use it is returning
a different object from getbuffer. There seems to be no rationale
set out for th
I would
personally suggest limiting support and going for ffmpeg (via ctypes
would be quickest, though a SWIG wrapping could make it more convenient).
Python wrapper for FFmpeg using Pyrex is available on google code (
http://code.google.com/p/pyffmpeg/)
___
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
2007/3/26, Pete Shinners <[EMAIL PROTECTED]>:
> My main question is what is the image and sound container passed back to
> Python?
> This single thing along would be worth a SoC if it could be implemented across
> all libraries.
>
> Will your image objects be transferrable to PIL, Pygame, PyOpengl
Lino Mastrodomenico wrote:
> Hello everyone,
>
> I would like to participate as a student in google Summer of Code and
> I'm interested in feedback on a multimedia library for Python.
>
> The library I propose should have the following features:
> * the capability to extract and decompress vi
Travis Oliphant wrote:
> Hi Carl and Greg,
>
> Here is my updated PEP which incorporates several parts of the
> discussions we have been having.
>
And here is the actual link:
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/doc/pep_buffer.txt
> -Travis
>
>
>
> __
Hi Carl and Greg,
Here is my updated PEP which incorporates several parts of the
discussions we have been having.
-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://ma
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
Pete Shinners wrote:
> Will your image objects be transferrable to PIL, Pygame, PyOpengl, Numpy,
> Pythonmagick, Pycairo, wxPython, etc? It would be best if this could avoid the
> "fromstring/tostring" mojo that always requires and extra copy of the data for
> each transfer.
This would be an exce
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
Lino Mastrodomenico gmail.com> writes:
> I would like to participate as a student in google Summer of Code and
> I'm interested in feedback on a multimedia library for Python.
>
> The library I propose should have the following features:
> * the capability to extract and decompress video and
On 3/25/07, Mike Brown <[EMAIL PROTECTED]> wrote:
> From your proposal:
>
> > 2) In all modules, Follow the new RFC 2396 in favour of RFC 1738 and RFC
> > 1808.
>
> The "new" RFC 2396 was superseded by STD 66 (RFC 3986) two years ago. Your
> failure to notice this development doesn't bode well :)
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
On 3/24/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> If I were to summarize your proposal, it would be "merge, clean up, and
> add features to urllib, urllib2, and urlparse". Sounds reasonable for
> Python 3, but remember that you will need to update any standard library
> module that current
(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
16 matches
Mail list logo
