> I wouldn't change the export formats used for the 'u' typecode at  
> all in 3.4 - I'd add new typecodes to array that match any new  
> struct format characters and are exported accordingly. 'u' would  
> *never* become a formally defined struct character, instead  
> lingering in the array module as a legacy of the narrow/wide build  
> distinction.

I think it is a desirable property that for an array A and an index
I, that A[I] == memoryview(A)[I]. Exporting the elements of an 'u'
array as integers would break that property.

So if we do want to support Unicode arrays (which some people apparently
want to see - I haven't heard anybody saying they actually *need* such
a type), the buffer type of it should be "unicode", in some form, not
"number".

I would be fine with deprecating the 'u' type arrays, acknowledging
that the Py_UNICODE element type is even more useless now than before.
If that is done, there is no point in fixing anything about it. If
it exports using the 'u' and 'w' codes - fine. If then memoryview
doesn't work properly - fine; this is a deprecated feature.

It should be fixed only if we want to support it "properly" (which I
believe this patch would do).