Martin v. Löwis added the comment: > 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15625> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
