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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XCWYIHEMQXUA5HEOD3UWRPVAI4PM5E7L/ Code of Conduct: http://python.org/psf/codeofconduct/
