Thank you, Martin and Stephen, for the suggestions and comments.
For your information:
We decided that all NumPy arrays of unicode strings will use UCS4 for
internal representation. When an element of the array is selected, a
unicodescalar (which inherits directly from the unicode builtin type
> "Travis" == Travis E Oliphant <[EMAIL PROTECTED]> writes:
Travis> Numpy supports arrays of arbitrary fixed-length "records".
Travis> It is much more than numeric-only data now. One of the
Travis> fields that a record can contain is a string. If strings
Travis> are supported
Travis E. Oliphant wrote:
> Numpy supports arrays of arbitrary fixed-length "records". It is
> much more than numeric-only data now. One of the fields that a
> record can contain is a string. If strings are supported, it makes
> sense to support unicode strings as well.
Hmm. How do you support
Martin v. Löwis wrote:
> Travis E. Oliphant wrote:
>
>>Currently that means that they are "unicode" strings of basic size UCS2
>>or UCS4 depending on the platform. It is this duality that has some
>>people concerned. For all other data-types, NumPy allows the user to
>>explicitly request a bi
Travis E. Oliphant wrote:
> Currently that means that they are "unicode" strings of basic size UCS2
> or UCS4 depending on the platform. It is this duality that has some
> people concerned. For all other data-types, NumPy allows the user to
> explicitly request a bit-width for the data-type.
This is a design question which is why I'm posting here. Recently the
NumPy developers have become more aware of the difference between UCS2
and UCS4 builds of Python. NumPy arrays can be of Unicode type. In
other words a NumPy array can be made of up fixed-data-length unicode
strings.
Cur
