[Python-Dev] PEP: Adding data-type objects to Python

Josiah Carlson jcarlson at uci.edu
Sat Oct 28 20:42:36 CEST 2006


"M.-A. Lemburg" <mal at egenix.com> 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



More information about the Python-Dev mailing list