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
Talin wrote:
> I'm right in the middle of typing up a largish post to go on the
> Python-3000 mailing list about this issue. Maybe we should move it over
> there, since its likely that any path reform will have to be targeted at
> Py3K...?
I'd say that any proposal that cannot be fit into the
On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote:
This mechanism is probably a hack because it'n not possible to add
C accessible
fields to type objects, on the other hand it is extensible (in
principle, at least).
I better start rewriting PyObjC then :-). PyObjC stores some addition
i
"Travis Oliphant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Examples of Need
[snip]
< I could have also included examples from PyGame, OpenGL, etc. I thought
>people were more aware of this argument as we've made it several times
>over the years. It's just taken this long to
I'm right in the middle of typing up a largish post to go on the
Python-3000 mailing list about this issue. Maybe we should move it over
there, since its likely that any path reform will have to be targeted at
Py3K...?
Mike Orr wrote:
> I just saw the Path object thread ("PEP 355 status", Sept-
I just saw the Path object thread ("PEP 355 status", Sept-Oct), saying
that the first object-oriented proposal was rejected. I'm in favor of
the "directory tuple" approach which wasn't mentioned in the thread.
This was proposed by Noal Raphael several months ago: a Path object
that's a sequence of
One thing I'm curious about in the ctypes vs this PEP debate is the following.
How do the approaches differ in practice if I'm developing a library that wants
to accept various image formats that all describe the same thing: rgb data.
Let's say for now all I want to support is two different image
""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
> The only benefit I imagine would be for an extension module library
> writer and for users of the struct and array modules. But, other than
> that, I don't know. It actually doesn't have to be exposed to Python.
> I used Python notation in the PEP to explain what is basically a
> C-structur
I submitted patch 1462525 awhile back to
solve the problem described even longer ago in
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
and I'm wondering what my appropriate next steps are. Honestly, I don't
care if you take my patch or someone else's proposed solution, but I
Paul Moore wrote:
> On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>>Martin v. Löwis wrote:
>>
>>>[...] because I still don't quite understand what the PEP
>>>wants to achieve.
>>>
>>
>>Are you saying you still don't understand after having read the extended
>>buffer protocol PEP, yet?
"Paul Moore" <[EMAIL PROTECTED]> wrote:
> On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> > Martin v. Löwis wrote:
> > > [...] because I still don't quite understand what the PEP
> > > wants to achieve.
> > >
> >
> > Are you saying you still don't understand after having read the extende
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
On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > [...] because I still don't quite understand what the PEP
> > wants to achieve.
> >
>
> Are you saying you still don't understand after having read the extended
> buffer protocol PEP, yet?
I can't speak for Martin
Travis Oliphant schrieb:
> I think it actually is. Perhaps I'm wrong, but a type-object is still a
> special kind of an instance of a meta-type. I once tried to add
> function pointers to a type object by inheriting from it. But, I was
> told that Python is not set up to handle that. Maybe I
Martin v. Löwis wrote:
> Stephan Tolksdorf schrieb:
>
>>While Travis' proposal encompasses the data format functionality within
>>the struct module and overlaps with what ctypes has to offer, it does
>>not aim to replace ctypes.
>
>
> This discussion could have been a lot shorter if he had sai
Travis Oliphant schrieb:
> For example, I'm pretty sure you were the one who made me aware that you
> can't just extend the PyTypeObject. Instead you extended the tp_dict of
> the Python typeObject to store some of the extra information that is
> needed to describe a data-type like I'm proposin
Thomas Heller wrote:
>
> (I tried to read the whole thread again, but it is too large already.)
>
> There is a (badly named, probably) api to access information
> about ctypes types and instances of this type. The functions are
> PyObject_stgdict(obj) and PyType_stgdict(type). Both return a
> '
Martin v. Löwis wrote:
> Travis E. Oliphant schrieb:
>
>>But, there are distinct disadvantages to this approach compared to what
>>I'm trying to allow. Martin claims that the ctypes approach is
>>*basically* equivalent but this is just not true.
>
>
> I may claim that, but primarily, my goal
Martin v. Löwis wrote:
> Travis Oliphant schrieb:
>
>>The big difference, however, is that by going this route you are forced
>>to use the "type object" as your data-format "instance".
>
>
> Since everything is an object (an "instance) in Python, this is not
> such a big difference.
>
I think
Travis Oliphant schrieb:
> Greg Ewing wrote:
>> Travis Oliphant wrote:
>>
>>
>>>Part of the problem is that ctypes uses a lot of different Python types
>>>(that's what I mean by "multi-object" to accomplish it's goal). What
>>>I'm looking for is a single Python type that can be passed around a
Stephan Tolksdorf schrieb:
> While Travis' proposal encompasses the data format functionality within
> the struct module and overlaps with what ctypes has to offer, it does
> not aim to replace ctypes.
This discussion could have been a lot shorter if he had said so.
Unfortunately (?) he stated t
Travis Oliphant schrieb:
> The big difference, however, is that by going this route you are forced
> to use the "type object" as your data-format "instance".
Since everything is an object (an "instance) in Python, this is not
such a big difference.
> This is
> fitting a square peg into a round
Nick Coghlan wrote:
> Travis E. Oliphant wrote:
>
>>However, the existence of an alternative strategy using a single Python
>>type and multiple instances of that type to describe binary data (which
>>is the NumPy approach and essentially the array module approach) means
>>that we can't just a-p
Travis E. Oliphant schrieb:
> But, there are distinct disadvantages to this approach compared to what
> I'm trying to allow. Martin claims that the ctypes approach is
> *basically* equivalent but this is just not true.
I may claim that, but primarily, my goal was to demonstrate that the
propos
Martin v. Löwis wrote:
> Travis Oliphant schrieb:
>> Function pointers are "supported" with the void data-type and could be
>> more specifically supported if it were important. People typically
>> don't use the buffer protocol to send function-pointers around in a way
>> that the void descript
Martin v. Löwis wrote:
> Travis Oliphant schrieb:
>
>>So, the big difference is that I think data-formats should be
>>*instances* of a single type.
>
>
> This is nearly the case for ctypes as well. All layout descriptions
> are instances of the type type. Nearly, because they are instances
> of
Michael Chermside wrote:
> In this email I'm responding to a series of emails from Travis
> pretty much in the order I read them:
>
>>
>> In the mean-time, how are other packages supposed to communicate
>> binary information about data with each other?
>
> Here we disagree.
>
> I haven't used
In this email I'm responding to a series of emails from Travis
pretty much in the order I read them:
Travis Oliphant writes:
> I'm saying we should introduce a single-object mechanism for
> describing binary data so that the many-object approach of c-types
> does not become some kind of de-fac
> > It might be better not to consider "bit" to be a
> > type at all, and come up with another way of indicating
> > that the size is in bits. Perhaps
> >
> > 'i4' # 4-byte signed int
> > 'i4b' # 4-bit signed int
> > 'u4' # 4-byte unsigned int
> > 'u4b' # 4-bit unsigned int
>
Travis E. Oliphant wrote:
> However, the existence of an alternative strategy using a single Python
> type and multiple instances of that type to describe binary data (which
> is the NumPy approach and essentially the array module approach) means
> that we can't just a-priori assume that the way
On 10/31/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> In order to make sense of the data-format object that I'm proposing you
> have to see the need to share information about data-format through an
> extended buffer protocol (which I will be proposing soon). I'm not
> going to try to argue th
34 matches
Mail list logo
