Re: [Python-Dev] PEP: Adding data-type objects to Python
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(ctypes.c_long) py> type(ctypes.c_double) py> type(ctypes.c_double).__bases__ (,) py> type(ctypes.Structure) py> type(ctypes.Array) py> type(ctypes.Structure).__bases__ (,) py> type(ctypes.Array).__bases__ (,) So if your requirement is "all layout descriptions ought to have the same type", then this is (nearly) the case: they are instances of type (rather then datatype, as in your PEP). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 of some character. But, this can change in the data-format object. I can see that the Unicode description needs to be improved. > The definition should talk about Unicode code points. > The number of bytes then determines whether you can only > represent the ASCII subset (1 byte), UCS2 (2 bytes, BMP only) > or UCS4 (4 bytes, all currently assigned code points). Yes, you are correct. A string of unicode characters should really be represented in the same way that an array of integers is represented for a data-format object. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP: Extending the buffer protocol to share array information.
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 Created: 28-Aug-2006 Python-Version: 2.6 Abstract This PEP proposes extending the tp_as_buffer structure to include function pointers that incorporate information about the intended shape and data-format of the provided buffer. In essence this will place something akin to the array interface directly into Python. Rationale 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-buffer is interpreted correctly. The NumPy project introduced an array interface (http://numpy.scipy.org/array_interface.shtml) through a set of attributes on the object itself. While this approach works, it requires attribute lookups which can be expensive when sharing many small arrays. One of the key reasons that users often request to place something like NumPy into the standard library is so that it can be used as standard for other packages that deal with arrays. This PEP provides a mechanism for extending the buffer protocol (which already allows data sharing) to add the additional information needed to understand the data. This should be of benefit to all third-party modules that want to share memory through the buffer protocol such as GUI toolkits, PIL, PyGame, CVXOPT, PyVoxel, PyMedia, audio libraries, video libraries etc. Proposal Add a bf_getarrayinfo function pointer to the buffer protocol to allow objects to share additional information about the returned memory pointer. Add the TP_HAS_EXT_BUFFER flag to types that define the extended buffer protocol. Specification: static int bf_getarrayinfo (PyObject *obj, Py_intptr_t **shape, Py_intptr_t **strides, PyObject **dataformat) Inputs: obj -- The Python object being questioned. Outputs: [function result] -- the number of dimensions (n) *shape -- A C-array of 'n' integers indicating the shape of the array. Can be NULL if n==0. *strides -- A C-array of 'n' integers indicating the number of bytes to jump to get to the next element in each dimension. Can be NULL if the array is C-contiguous (or n==0). *dataformat -- A Python object describing the data-format each element of the array should be interpreted as. Discussion Questions: 1) How is data-format information supposed to be shared? A companion proposal suggests returning a data-format object which carries the information about the buffer area. 2) Should the single function pointer call be extended into multiple calls or should it's arguments be compressed into a structure that is filled? 3) Should a C-API function(s) be created which wraps calls to this function pointer much like is done now with the buffer protocol? What should the interface of this function (or these functions) be. 4) Should a mask (for missing values) be shared as well? Reference Implementation Supplied when the PEP is accepted. Copyright This document is placed in the public domain. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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. > a 5-bit signed int field and a 5-bit unsigned int > field. Good point. > > 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 > I like this. Very nice. I think that's the right way to look at it. > (Next we can have an argument about whether bit > fields should be packed MSB-to-LSB or vice versa...:-) I guess we need another flag / attribute to indicate that. The other thing that needs to be discussed at some point may be a way to indicate the floating-point format. I've basically punted on this and just meant 'f' to mean "platform float" Thus, you can't use the data-type object to pass information between two platforms that don't share a common floating point representation. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 and >>> explains binary data. >> >> It's not clear that multi-object is a bad thing in and >> of itself. It makes sense conceptually -- if you have >> a datatype object representing a struct, and you ask >> for a description of one of its fields, which could >> be another struct or array, you would expect to get >> another datatype object describing that. Yes, exactly. This is what the Python type I'm proposing does as well. So, perhaps we are misunderstanding each other. The difference is that data-types are instances of the data-type (data-format) object instead of new Python types (as they are in ctypes). > > I've tried to clarify this in another post. Basically, what I don't > like about the ctypes approach is that it is multi-type (every new > data-format is a Python type). > I should clarify that I have no opinion about the ctypes approach for what ctypes does with it. I like ctypes and have adapted NumPy to make it easier to work with ctypes. I'm saying that I don't like the idea of forcing this approach on everybody else who wants to describe arbitrary binary data just because ctypes is included. Now, if it is shown that it is indeed better than a simpler instances-of-a-single-type approach that I'm basically proposing then I'll be persuaded. 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 ctypes did it is the only or best way. The examples of "missing features" that Martin has exposed are not show-stoppers. They can all be easily handled within the context of what is being proposed. I can modify the PEP to show this. But, I don't have the time to spend if it's just all going to be rejected in the end. I need some encouragement in order to continue to invest energy in pushing this forward. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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. > > > It's not clear that multi-object is a bad thing in and > of itself. It makes sense conceptually -- if you have > a datatype object representing a struct, and you ask > for a description of one of its fields, which could > be another struct or array, you would expect to get > another datatype object describing that. > > Can you elaborate on what would be wrong with this? > > Also, can you clarify whether your objection is to > multi-object or multi-type. They're not the same thing -- > you could have a data structure built out of multiple > objects that are all of the same Python type, with > attributes distinguishing between struct, array, etc. > That would be single-type but multi-object. I've tried to clarify this in another post. Basically, what I don't like about the ctypes approach is that it is multi-type (every new data-format is a Python type). In order to talk about all these Python types together, then they must all share some attribute (or else be derived from a meta-type in C with a specific function-pointer entry). I think it is simpler to think of a single Python type whose instances convey information about data-format. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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. > > > How does this compare with ctypes? Do we really need yet another, > incompatible way to describe C-like data structures in the standarde > library? There is a lot of subtlety in the details that IMHO clouds the central issue which I will try to clarify here the way I see it. First of all: 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 that right now because there are a lot of people who can do that. So, I'm going to assume that you see the need for it. If you don't, then just suspend concern about that for the moment. There are a lot of us who really see the need for it. Now: To describe data-formats ctypes uses a Python type-object defined for every data-format you might need. In my view this is an 'over-use' of the type-object and in fact, to be useful, requires the definition of a meta-type that carries the relevant additions to the type-object that are needed to describe data (like function pointers to get data in and out of Python objects). My view is that it is un-necessary to use a different type object to describe each different data-type. The route I'm proposing is to define (in C) a *single* new Python type (called a data-format type) that carries the information needed to describe a chunk of memory. In this way *instances* of this new type define data-formats. In ctypes *instances* of the "meta-type" (i.e. new types) define data-formats (actually I'm not sure if all the new c-types are derived from the same meta-type). So, the big difference is that I think data-formats should be *instances* of a single type. There is no need to define a Python type-object for every single data-type. In fact, not only is there no need, it makes the extended buffer protocol I'm proposing even more difficult to use and explain. Again, my real purpose is the extended buffer protocol. These data-format type is a means to that end. If the consensus is that nobody sees a greater use of the data-format type beyond the buffer protocol, then I will just write 1 PEP for the extended buffer protocol. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 complex arrangements of types that reference each other. > If that is the case, then it's > easily supported once support for pointers is added. But it doesn't fit easily into the single-object model. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 5-bit unsigned int field. 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 (Next we can have an argument about whether bit fields should be packed MSB-to-LSB or vice versa...:-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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-object is a bad thing in and of itself. It makes sense conceptually -- if you have a datatype object representing a struct, and you ask for a description of one of its fields, which could be another struct or array, you would expect to get another datatype object describing that. Can you elaborate on what would be wrong with this? Also, can you clarify whether your objection is to multi-object or multi-type. They're not the same thing -- you could have a data structure built out of multiple objects that are all of the same Python type, with attributes distinguishing between struct, array, etc. That would be single-type but multi-object. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 said before, I can't tell whether it's important, as I still don't
know what the purpose of this PEP is. If it is to support a unification
of memory layout specifications, and if that unifications is also to
include ctypes, then yes, it is important. If it is to describe array
elements in NumArray arrays, then it might not be important.
For the usage of ctypes, the PEP void type is insufficient to describe
function pointers: you also need a specification of the signature of
the function pointer (parameter types and return type), or else you
can't use the function pointer (i.e. you can't call the function).
> Pointers are also "supported" with the void data-type. If pointers to
> other data-types were an important feature to support, then this could
> be added in many ways (a flag on the data-type object for example is how
> this is done is NumPy).
For ctypes, (I think) you need "true" pointers to other layouts, or
else you couldn't set up the memory correctly.
I don't understand how this could work with some extended buffer
protocol, though: would a buffer still have to be a contiguous piece
of memory? If you have structures with pointers in them, they
rarely point to contiguous memory.
> Unions are actually supported (just define two fields with the same
> offset).
Ah, ok. What's the string syntax for it?
> I don't know what you mean by "packed structs" (unless you are talking
> about alignment issues in which case there is support for it).
Yes, this is indeed about alignment; I missed it. What's the string
syntax for it?
> 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). If that is the case, then it's
> easily supported once support for pointers is added.
That's what I mean, yes. I'm not sure how it can easily be added,
though. Suppose you want to describe
struct item{
int key;
char* value;
struct item *next;
};
How would you do that? Something like
item = datatype([('key', 'i4'), ('value', 'S*'), ('next',
'what_to_put_here*')]
can't work: item hasn't been assigned, yet, so you can't
use it as the field type.
> I also don't know what you mean by "open-ended arrays." The data-format
> is meant to describe a fixed-size chunk of data.
I see. In C (and thus in ctypes), you sometimes have what C99 calls
"flexible array member":
struct PyString{
Py_ssize_t ob_refcnt;
PyObject *ob_type;
Py_ssize_t ob_len;
char ob_sval[];
};
where the ob_sval field can extend arbitrarily, as it is the last
member of the struct. Of course, this will give you dynamically-sized
objects (objects in C cannot really be "variable-sized", since the
size of a memory block has to be defined at allocation time, and
can't really change afterwards).
> String syntax is not needed to support all of these things.
Ok. That's confusing in the PEP: it's not clear whether all these
forms are meant to be equivalent, and, if not, which one is the most
generic one, and what aspects are missing in what forms. Also,
if you have a datatype which cannot be expressed in the string
syntax, what is its "str" attribute?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 added, > I don't know. As I just wrote in a few other messages: pointers, > unions, functions pointers, packed structs, incomplete/recursive > types. Also "flexible array members" (i.e. open-ended arrays). > I understand function pointers, pointers, and unions. 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. Pointers are also "supported" with the void data-type. If pointers to other data-types were an important feature to support, then this could be added in many ways (a flag on the data-type object for example is how this is done is NumPy). Unions are actually supported (just define two fields with the same offset). I don't know what you mean by "packed structs" (unless you are talking about alignment issues in which case there is support for it). 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). If that is the case, then it's easily supported once support for pointers is added. I also don't know what you mean by "open-ended arrays." The data-format is meant to describe a fixed-size chunk of data. String syntax is not needed to support all of these things. What I'm asking for and proposing is a way to construct an instance of a single Python type that communicates this data-format information in a standardized way. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 other > types. I'm asking what size-independent > information it's meant to convey. Ah. I see what you were saying now. I guess the 'bit' type is different (we actually don't have that type in NumPy so my understanding of it is limited). 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. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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.
>
>
> As a quick sanity check, please tell me where I went off track.
>
> it sounds to me like you are assuming that:
>
> (1) The memory chunk represents a single object (probably an array of
> some sort)
> (2) That subchunks can themselves be described by a (single?)
> repeating C struct.
> (3) You can't just use the C header, since you want this at run-time.
> (4) It would be enough if you could say
>
> This is an array of 500 elements that look like
>
> struct {
> int simple;
> struct nested {
>char name[30];
>char addr[45];
>int amount;
> }
>
Sure. I think that's pretty much it. I assume you mean object in the
general sense and not as in (Python object).
> (5) But is it not acceptable to use Martin's suggested ctypes
> equivalent of (building out from the inside):
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.
Remember the buffer protocol is in compiled code. So, as a result,
1) It's harder to construct a class to pass through the protocol using
the multiple-types approach of ctypes.
2) It's harder to interpret the object recevied through the buffer
protocol.
Sure, it would be *possible* to use ctypes, but I think it would be very
difficult. Think about how you would write the get_data_format C
function in the extended buffer protocol for NumPy if you had to import
ctypes and then build a class just to describe your data. How would you
interpret what you get back?
The ctypes "format-description" approach is not as unified as a single
Python type object that I'm proposing.
In NumPy, we have a very nice, compact description of complicated data
already available. Why not use what we've learned?
I don't think we should just *use ctypes because it's there* when the
way it describes binary data was not constructed with the extended
buffer protocol in mind.
The other option, of course, which would not introduce a new Python type
is to use the array interface specification and pass a list of tuples.
But, I think this is also un-necessarily wasteful because the sending
object has to construct it and the receiving object has to de-construct
it. The whole point of the (extended) buffer protocol is to communicate
this information more quickly.
-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 wxPython built in classes use numpy to >>speed up manipulation) would be very useful. > > > I'm doubtful that this PEP alone would allow zero-copy sharing of images > for display. Often, the libraries need the data in a different format. > So they need to copy, even if they could understand the other format. > However, the PEP won't allow "understanding" the format. If I know I > have an array of 4-byte values: which of them is R, G, B, and A? > You give a name to the fields: 'R', 'G', 'B', and 'A'. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP: Adding data-type objects to Python
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, please tell me where I went off track.
it sounds to me like you are assuming that:
(1) The memory chunk represents a single object (probably an array of
some sort)
(2) That subchunks can themselves be described by a (single?)
repeating C struct.
(3) You can't just use the C header, since you want this at run-time.
(4) It would be enough if you could say
This is an array of 500 elements that look like
struct {
int simple;
struct nested {
char name[30];
char addr[45];
int amount;
}
(5) But is it not acceptable to use Martin's suggested ctypes
equivalent of (building out from the inside):
class nested(Structure):
_fields_ = [("name", c_char*30), ("addr", c_char*45),
("amount", c_long)]
class struct(Structure):
_fields_ = [("simple", c_int), ("nested", nested)]
struct * 500
If I misunderstood, could you show me where?
If I did understand correctly, could you expand on why (5) is
unacceptable, given that ctypes is now in the core? (New and unknown,
I would understand -- but that is also true of any datatype proposal,
for the people who haven't already used it. I suspect that any
differences from Numpy would be a source of pain for those who *have*
used Numpy, but following Numpy exactly is ... not much simpler than
the above.)
Or are you just saying that "anything with a buffer interface should
also have a datatype object describing the layout in a standard way"?
If so, that makes sense, but I'm inclined to prefer the ctypes way, so
that most people won't ever have to worry about things like
endianness/strides/Fortan layout.
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
> ...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 code remedied that for passing it around to the OpenCV library. Just my $.02 Diez ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 of image formats, which have their whole own range of data formats. I could throw in audio formats (bits per sample, excess-N or signed or ulaw samples, mono/stereo/5.1/etc, order of the channels), and there's probably a whole slew of other areas that have their own sets of formats.If the datatype objects are subclassable, modules could initially start by adding their own formats. So, the "jackaudio" and "jillaudio" modules would have distinct sets of formats. But then later on it should be fairly easy for them to recognize each others formats. So, jackaudio would recognize the jillaudio format "msdos linear pcm" as being identical to its own "16-bit excess-32768".Hopefully eventually all audio module writers would get together and define a set of standard audio formats. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Adding data-type objects to Python
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 interface. I > certainly have not studied the options in any depth, but my gut feeling is > that the interface is too fat and too complex. I wonder if it's possible > to avoid this. I wonder if this is an example of all the methods sinking > to the base class. You've just described my number #1 concern with incorporating NumPy wholesale, and the reason I believe it would be nice to cherry-pick a couple of key components for the standard library, rather than adopting the whole thing. Travis has done a lot of work towards that goal (the latest result of which is this pre-PEP for describing the individual array elements in a way that is more flexible than the single character codes of the current array module). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
