[issue15625] Support u and w codes in memoryview

2016-05-25 Thread Марк Коренберг
Марк Коренберг added the comment: Trigger the same bug I want to effectively slice big unicode string. So I decide to use memoryview for that in order to eliminate memory copying. In [33]: a = array.array('u', 'превед') In [34]: m = memoryview(a) In [35]: m[2:] Out[35]: In [36]: m[0] ...

[issue15625] Support u and w codes in memoryview

2015-04-15 Thread Steve Dower
Steve Dower added the comment: Closing sounds good to me -- nosy: +steve.dower resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___

[issue15625] Support u and w codes in memoryview

2015-04-15 Thread Arnon Yaari
Arnon Yaari added the comment: The documentation already specifies that 'u' is deprecated and doesn't mention the 'w' code. I think we can close this issue. -- nosy: +wiggin15 ___ Python tracker rep...@bugs.python.org

[issue15625] Support u and w codes in memoryview

2012-10-03 Thread Jesús Cea Avión
Changes by Jesús Cea Avión j...@jcea.es: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___ ___

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Martin v . Löwis
Martin v. Löwis added the comment: My current inclination is still to apply Victor's patch from #13072 (which changes array to export the appropriate integer typecodes for 'u' arrays) and otherwise punt on this for 3.3 and try to sort out the mess for 3.4. I think this would be the

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Nick Coghlan
Nick Coghlan 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

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Martin v . Löwis
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,

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Nick Coghlan
Nick Coghlan added the comment: I guess the main alternative to deprecation that preserves the invariant you describe would be to propagate the u == Py_UNICODE definition to memoryview. Since we're trying to phase out Py_UNICODE, deprecation seems the more sensible course. Perhaps just a

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Stefan Krah
Stefan Krah added the comment: Martin v. Loewis rep...@bugs.python.org wrote: 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

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Stefan Krah
Stefan Krah added the comment: Well, apparently people do use 'u', see #15035. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Martin v . Löwis
Martin v. Löwis added the comment: #15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was technically incorrect, since it is based on Py_UNICODE, whereas the API in question uses UniChar (which apparently is a two-byte type). --

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Stefan Krah
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: #15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was technically incorrect, since it is based on Py_UNICODE, whereas the API in question uses UniChar (which apparently is a two-byte type).

[issue15625] Support u and w codes in memoryview

2012-08-16 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___

[issue15625] Support u and w codes in memoryview

2012-08-15 Thread Stefan Krah
Stefan Krah added the comment: Nick's comment in msg167963 got me thinking. Indeed, in Numpy the 'U' specifier is similar to the struct module's 's' format code, only for UCS4. So I'm questioning whether the current semantics of 'u' and 'w' used by array.array were ever intended by the PEP

[issue15625] Support u and w codes in memoryview

2012-08-15 Thread Martin v . Löwis
Martin v. Löwis added the comment: Travis: can you please comment on what the intended semantics of the 'u' and 'w' specifiers is, in PEP 3118? More specifically: - an array/memoryview with format 'u' can support exactly one-character values (i.e. unicode strings of length 1): true or false?

[issue15625] Support u and w codes in memoryview

2012-08-15 Thread Nick Coghlan
Nick Coghlan added the comment: I admit that the main thing that bothers me with the proposal in PEP 3118 is the inconsistency between c - bytes, while u, w - str This was less of an issue in 2.x (which was the main frame of reference when the PEP was written), with implicit str/unicode

[issue15625] Support u and w codes in memoryview

2012-08-11 Thread Martin v . Löwis
New submission from Martin v. Löwis: Currently, the following test case fails: import array a=array.array('u', 'foo') memoryview(a)==memoryview(a) False This is because the memoryview object doesn't support the u and w codes, as it should per PEP 3118. This patch fixes it. --

[issue15625] Support u and w codes in memoryview

2012-08-11 Thread Martin v . Löwis
Changes by Martin v. Löwis mar...@v.loewis.de: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15625 ___ ___