(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
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
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/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 :)
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
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
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
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
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
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
>
>
>
> __
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
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
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
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:
> > 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
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
16 matches
Mail list logo
