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.
