Christopher Barker wrote:
Better yet: Provide type codes for the “new” C exact width integer types: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html (and any number of tother references) I've always thought is was unfortunate that Python inherited C's compiler-specific type definitions. But it's nice to be able to write platform-independent code that deals with binary data. numpy as provided these pretty much forever: https://numpy.org/devdocs/user/basics.types.html in addition to the dtype objects, numpy uses character typecodes, where you can specify the number of bytes of the type: e.g. "i4" is a 32 bit (four byte) signed integer, "u4" is a 32 bit unsigned integer. it seems the array module could adopt a similar system. Allow supplying an integer itemsize value as the typecode with a
positive value for unsigned or a negative value for signed. this seem pretty "magic" -- why not simply extend the typecode system as above?
It doesn't seem too magical to me. Nevertheless, I do like your suggestion a little better than mine.
Allow supplying a simple slice as the typecode defining the smallest rage of values that an item should be able to represent. this is even more magic -- it's only practical to provide types that are a
standard numbe rof bytes: 1,2,4,8 And this makes the goal of knowing exactly how many bytes your type is using even harder.
How often is knowing the itemsize the code will produce the most important goal? More often, one simply wants the most space-efficient type that can handle values within a particular range, whatever that size might be.
The array function object would also support indexing to produce a curried array function with the given a slice as its first argument. When either the signed or unsigned item type of a given size could encompass the given range, then the unsigned type would be used. even more magic, and more confusing -- why would you want this? i have to say, I've been staring at a a bit, and am still not quite sure what this is intended to do, and why? How does a slice object help here???
A slice is a specification of a range of values, so seems like the most obvious type of thing to pass as a range of values that the item must be able to represent. The currying is simply a means of using the slice notation rather than having to create a slice using the `slice` function.
# Signed short items initialized with [1, 2, 3] a = array.array(slice(-1, 200), Range(1, 4)) # or... a = array.array-1:200) # Unsigned 4-byte items (int (I) or long (L) depending on platform) a = array.array(slice(0, 0x90_00_00_00)) # or... a = array.array0:0x90_00_00_00 # or… a = array.array0:0x70_00_00_00 # Would fit into signed or unsigned. -CHB