Nick Coghlan added the comment: While I agree this is important (e.g. I know Dave started looking into this as getting NumPy working is currently a blocker for Fedora migrating their Python 3 stack to 3.3), the burden is definitely on the NumPy side to get the code point values using the right byte order before handing them over to the CPython API. If the sanity checks in the Unicode implementation are firing, it means something is still wrong on the NumPy side (perhaps erroneous unit tests, as Stefan reports).
>From the point of view of CPython, an array of byte-swapped code points isn't >text, it's an array of 16 or 32 bit integers, and NumPy's text handling needs >to work within that constraint. FWIW, with regard to Martin's tangential comment about appropriate use of the tracker, I'm personally fine with using the tracker for 'I found this problem, attempted to fix it (but failed), here's my attempt'. It's part of the wide spectrum of issue reporting that ranges from 'I found this problem, but have no idea what is causing it or where to even begin trying to fix it' through 'I found this problem, here's a fix that worked for me' all the way to 'I found this problem, here's a fix that works on multiple platforms with new tests, insightful doc adjustments and a pony' :) ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15540> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
