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 subtypes of the type type:
py> type(c
M.-A. Lemburg wrote:
> Travis E. Oliphant wrote:
>
> I understand and that's why I'm asking why you made the range
> explicit in the definition.
>
In the case of NumPy it was so that String and Unicode arrays would both
look like multi-length string "character" arrays and not arrays of
arrays
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
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> The 'bit' type re-intprets the size information to be in units of "bits"
>> and so implies a "bit-field" instead of another data-format.
>
> Hmmm, okay, but now you've got another orthogonality
> problem, because you can't distinguish between e.g.
Travis Oliphant wrote:
> 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 an
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 and
>>explains binary data.
>
>
Armin Rigo wrote:
> Hi Travis,
>
> On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
>
>>This PEP proposes adapting the data-type objects from NumPy for
>>inclusion in standard Python, to provide a consistent and standard
>>way to discuss the format of binary data.
Travis Oliphant wrote:
> I'm not sure I understand what you mean by "incomplete / recursive"
> types unless you are referring to something like a node where an element
> of the structure is a pointer to another structure of the same kind
> (like used in linked-lists or trees).
Yes, and more co
Travis Oliphant wrote:
> The 'bit' type re-intprets the size information to be in units of "bits"
> and so implies a "bit-field" instead of another data-format.
Hmmm, okay, but now you've got another orthogonality
problem, because you can't distinguish between e.g.
a 5-bit signed int field and a
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 and
> explains binary data.
It's not clear that multi-obj
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 description wouldn't be enough.
As I
Martin v. Löwis wrote:
> Robert Kern schrieb:
>
>>>As I unification mechanism, I think it is insufficient. I doubt it
>>>can express all the concepts that ctypes supports.
>>
>>What do you think is missing that can't be added?
>
>
> I can factually only report what is missing. Whether it can be
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>
>
>>Greg Ewing wrote:
>
>
>>>What exactly does "bit" mean in that context?
>>
>>Do you mean "big" ?
>
>
> No, you've got a data type there called "bit",
> which seems to imply a size, in contradiction
> to the size-independent nature of the o
Jim Jewett wrote:
> Travis E. Oliphant wrote:
>
>
>>Two packages need to share a chunk of memory (the package authors do not
>>know each other and only have and Python as a common reference). They
>>both want to describe that the memory they are sharing has some
>>underlying binary structure.
>
Martin v. Löwis wrote:
> Josiah Carlson schrieb:
>
>>One could also toss wxPython, VTK, or any one of the other GUI libraries
>>into the mix for visualizing those images, of which wxPython just
>>acquired no-copy display of PIL images, and being able to manipulate
>>them with numpy (of which some
Travis E. Oliphant wrote:
> Two packages need to share a chunk of memory (the package authors do not
> know each other and only have and Python as a common reference). They
> both want to describe that the memory they are sharing has some
> underlying binary structure.
As a quick sanity check, p
> ...in the cases I have seen, which includes BMP, TGA, uncompressed TIFF,
> a handful of platform-specific bitmap formats, etc., you _always_ get
> them in RGBA order. If the alpha channel is to be left out, then you
> get them as RGB.
Mac OS X unfortunately uses ARGB. Writing some alti-vec co
Would it be possible to make the data-type objects subclassable, with the subclasses being able to override the equality test?The range of data types that you've specified in the PEP are good enough for most general use, and probably for NumPy as well, but someone already came up with the example o
Neal Becker wrote:
> I have watched numpy with interest for a long time. My own interest is to
> possibly use the c-api to wrap c++ algorithms to use from python.
>
> One thing that has concerned me, and continues to concern me with this
> proposal, is that it seems to suffer from a very fat inte
19 matches
Mail list logo
