[issue8990] array constructor and array.fromstring should accept bytearray.

Antoine Pitrou added the comment: The patches were committed in r84403. Thank you very much! -- resolution: -> fixed stage: unit test needed -> committed/rejected status: open -> closed versions: -Python 3.1 ___ Python tracker

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Removed file: http://bugs.python.org/file18607/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Added file: http://bugs.python.org/file18698/tostring_usage.diff ___ Python tracker ___ ___ Python-bugs-list mailin

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: That sounds reasonable. I've updated the patch to keep the old test_tofromstring testcase. I'll also attach another patch in a moment that removes what I'm reasonably sure is all the uses of array.tostring and .fromstring in the standard library and the oth

[issue8990] array constructor and array.fromstring should accept bytearray.

Antoine Pitrou added the comment: The patch shouldn't remove the tests for tostring()/fromstring() (they might be deprecated, but they are still supported). -- ___ Python tracker __

[issue8990] array constructor and array.fromstring should accept bytearray.

Antoine Pitrou added the comment: >From a quick glance, the latest patch looks ok. -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file17828/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Hello again, sorry for the absense. Victor, thanks for the input. I've attached a new patch that checks the PyErr_WarnEx return value. -- Added file: http://bugs.python.org/file18607/tofrombytes.diff ___ Python tra

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Removed file: http://bugs.python.org/file18606/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Added file: http://bugs.python.org/file18606/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8990] array constructor and array.fromstring should accept bytearray.

STINNER Victor added the comment: I prefer the second solution (add to/frombytes, deprecate to/fromstring) because I prefer the new method names and it keeps backward compatibility (until we choose to remove the old methods, which should be in Python 3.3). About the patch (tofrombytes.diff).

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Removed file: http://bugs.python.org/file17827/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Added file: http://bugs.python.org/file17828/tofrombytes.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Secondly, this is my attempt to add the more sensibly named {to|from}bytes methods, and to deprecate {to|from}string. I doubt it's perfect, maybe there's some policy on deprecating methods that I didn't find? This may be better discussed in a separate forum,

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Two more patches: Firstly, this patch (array_3.2_fromstring.diff) is nearly identical to array2.diff. "y*" would (again) have to be changed to "s*" to apply this to 3.1 -- Added file: http://bugs.python.org/file17826/array_3.2_fromstring.diff ___

[issue8990] array constructor and array.fromstring should accept bytearray.

STINNER Victor added the comment: array2.diff: - can you reindent the line "Py_ssize_t old_size = Py_SIZE(self);"?(even if it's not part of your patch) - you can avoid the "char *str;" variable (use directly buffer.buf) -- > I changed "s#" to "y*". This means that str arguments are no longe

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: OK, here's the new patch. I added tests for array(typecode, bytearray(b'abab')), a.extend(b'123') and a.extend(bytearray(b'123')). @Victor: int itemsize is the array's item size, buffer.itemsize is the strings' (and must be 1) PROBLEM with this patch: I ch

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Thanks for the input. I'm going to re-work the patch a bit (releasing buffers and such) and add a test within the next few days. The question remains whether or not to accept other buffers with itemsize == 1. The way I understand it, fromstring already accep

[issue8990] array constructor and array.fromstring should accept bytearray.

STINNER Victor added the comment: About the patch: - Why not reading itemsize from buffer.itemsize? - A test would be nice in Lib/test/test_array.py (in test_tofromstring?). Please add also a.extend(bytearray(b'xjxjx')) to the test suite. I agree that it is a bugfix and so i can be applied

[issue8990] array constructor and array.fromstring should accept bytearray.

Antoine Pitrou added the comment: On the principle the patch looks good. In practice, it lacks a call to `PyBuffer_Release(&buffer)` in the various error cases (before returning NULL). It also lacks some tests in Lib/test/test_array.py. > In 3.x unicode type was renamed to str and str to byte

[issue8990] array constructor and array.fromstring should accept bytearray.

Alexander Belopolsky added the comment: > This, to me, implies that .fromstring should accept bytearray (though > probably not general buffer objects). In 2.x, I understand .fromstring > to initialize an array from machine bytes read into a string, but not > .fromunicode. This is *not* a text m

[issue8990] array constructor and array.fromstring should accept bytearray.

Terry J. Reedy added the comment: Whatever is done, I think a bytearray should be handled the same as bytes. It must be that they give the same result. In basic operations, I believe that bytearrays can *always* substitute for bytes. "Bytes and bytearray objects contain single bytes – the for

[issue8990] array constructor and array.fromstring should accept bytearray.

Alexander Belopolsky added the comment: Thomas' patch does more than just allow bytearray. It allows any object that can present itself as a buffer with byte-size items. It is a bit unfortunate that such method will end up being called "fromstring" in 3.x.With string being unicode, this

[issue8990] array constructor and array.fromstring should accept bytearray.

Terry J. Reedy added the comment: Summary: real bug, needs test, patch provided, looks plausible but I am not qualified to even read-review it, let alone apply and test. (I am removing 3.3 because that is only listed for syntax feature requests that cannot go into 3.2 because of its moratoriu

[issue8990] array constructor and array.fromstring should accept bytearray.

New submission from Thomas Jollans : Currently, the array constructor, if given a bytearray, detects this with PyByteArray_Check, and hands it on to array_fromstring, which does not support bytearray (by using "s#" with PyArg_ParseTuple) and raises TypeError. >>> array('h', bytearray(b'xyxyxyx