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
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.
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.
Why
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
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, it makes
