"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: > > Travis E. Oliphant wrote: > > M.-A. Lemburg wrote: > >> Travis E. Oliphant wrote: > >>> ------------------------------------------------------------------------ > >>> > >>> PEP: <unassigned> > >>> Title: Adding data-type objects to the standard library > >>> Attributes > >>> > >>> kind -- returns the basic "kind" of the data-type. The basic > >>> kinds > >>> are: > >>> 't' - bit, > >>> 'b' - bool, > >>> 'i' - signed integer, > >>> 'u' - unsigned integer, > >>> 'f' - floating point, > >>> 'c' - complex floating point, > >>> 'S' - string (fixed-length sequence of char), > >>> 'U' - fixed length sequence of UCS4, > >> Shouldn't this read "fixed length sequence of Unicode" ?! > >> The underlying code unit format (UCS2 and UCS4) depends on the > >> Python version. > > > > Well, in NumPy 'U' always means UCS4. So, I just copied that over. See > > my questions at the bottom which talk about how to handle this. A > > data-format does not necessarily have to correspond to something Python > > represents with an Object. > > Ok, but why are you being specific about UCS4 (which is an internal > storage format), while you are not specific about e.g. the > internal bit size of the integers (which could be 32 or 64 bit) ?
I think that even on 64 bit platforms, using 'int' or 'long' generally means 32 bit. In order to get 64 bit ints, one needs to use 'long long'. Sharing some of the codes with the struct module, though arbitrary, doesn't seem like a bad idea to me. Of course offering specifically 32 and 64 bit ints would make sense to me. - Josiah _______________________________________________ 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
