[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Antoine Pitrou : -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou added the comment: The patch is committed in r68200, r68202. Thanks! ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Martin v. Löwis : -- assignee: -> pitrou resolution: -> accepted ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Martin v. Löwis : -- keywords: -needs review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan added the comment: Finally got around to looking at the most recent patch (issue4580-2.patch). It looks good to me. I still think something needs to change when it comes to item assignment for memoryviews with itemsize > 1, but that's not as urgent as fixing the rest of the slicing

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou added the comment: Nick, sorry for waving at you again, but do you have time for a review? Otherwise, is it ok if I commit the patch as is? (it solves the problems and there's no API or feature change anyway) ___ Python tracker

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Barry A. Warsaw : -- priority: high -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou added the comment: Any news? ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailm

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou added the comment: > We just need to finish the job of making the convenience wrapper > actually able to handle the task we would like it to handle. Your latest > patch goes a long way towards doing that for the 1 dimensional case - if > Travis doesn't get to it first, I plan on t

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan added the comment: Trying another way of getting the point across... if Py_buffer wasn't defined in PEP 3118, there would have to be some *other* API there whereby the memoryview implementation could ask an object for a description of the data layout of the object's buffer. It is P

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan added the comment: I still don't see the problem: Py_buffer is a minimal description of a region of memory. No more, no less. It doesn't *do* anything, it's just a description. memoryview is an object that will (when it's finished) provide an easy way to access the memory of anoth

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou added the comment: > > I'm trying to be practical. If the additional shape/strides storage is > > in Py_buffer, it can benefit anyone wanting to create a subview or doint > > to do something else with shape and strides. If the storage is in > > memoryview, it only benefits memoryv

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan added the comment: > I'm trying to be practical. If the additional shape/strides storage is > in Py_buffer, it can benefit anyone wanting to create a subview or doint > to do something else with shape and strides. If the storage is in > memoryview, it only benefits memoryview. I'm

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > Antoine, regarding the shapes and strides info for subviews: don't think > of it as reallocating or altering the shape of the underlying buffer. > Think of it as having separate shape and stride information for the > contents of the underlyi

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Antoine's latest patch looks to me like it will fix the current actual errors in the 1-D case. Something that may also be considered part of this bug is the fact that "m[i] = m[i]" doesn't currently work for itemsize > 1. There is a XXX commen

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Alexander Belopolsky <[EMAIL PROTECTED]>: -- nosy: +belopolsky ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-lis

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: It's quite possible that I misread the array.array implementation since I only glanced at the code where it fills in the Py_buffer details - I saw the point where it set shape to NULL, but there may have been code later on to fill it in correctl

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: New patch addressing the above issues. You can also review it at http://codereview.appspot.com/10441 Added file: http://bugs.python.org/file12321/issue4580-2.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Thanks for your comments. I'll provide an updated patch later today and let you take a look. > * Memoryview object should report it's length as self->view.shape[0] > unless self->view.shape is NULL (indicating in this case a 0-d array or > s

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > * I don't see where array.array getbuf implementation is broken. It > looks correct to me. It sets view.shape to NULL unless the consumer > asked for the shape information to be reported in which case it sets it > equal to a pointer to t

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Travis Oliphant <[EMAIL PROTECTED]> added the comment: Another comment on statements made * I don't see where array.array getbuf implementation is broken. It looks correct to me. It sets view.shape to NULL unless the consumer asked for the shape information to be reported in which case it se

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Travis Oliphant <[EMAIL PROTECTED]> added the comment: My perspective on statements made: * Memoryview object should report it's length as self->view.shape[0] unless self->view.shape is NULL (indicating in this case a 0-d array or scalar). In this case, it should raise an error. * The buff

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Travis Oliphant <[EMAIL PROTECTED]> added the comment: I will take some time in the next week to look at this issue. Thank you for bringing these bugs to my attention. I did not finish the memoryview implementation, due to other demands on my time. I appreciate the efforts of so many to pick

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Thanks for your two messages, Nick, they make things clearer for me and I'll make the necessary modifications in the patch some time today. ___ Python tracker <[EMAIL PROTECTED]>

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Regarding ndim > 0 and shape=NULL, the PEP doesn't allow it. Any code that does it is already broken - we're just making it fail cleanly at the point where it is broken rather than in some obscure fashion somewhere else. ___

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The reason memoryview's current len() implementation is wrong is because its indexing is per element in the original object, not per byte: >>> a = array('i', range(10)) >>> m = memoryview(a) >>> for i in range(len(m)): ... print(m[i]) ... b'\

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Hi Nick, > 1. memoryview needs to be fixed so that internally self->view.len is > always the length in bytes, even after taking a slice of the view This is in my patch, unless I'm missing something? > 2. memoryview needs to be fixed so that

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The patch still gets the length of memory view objects wrong - it just makes it *consistently* wrong so that the specific assignment being tested appears to work. Note the following behaviour with the current memoryview : >>> from array import

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Sorry for the whitespace changes, here is a patch that has less of them... hope that helps ;-S Added file: http://bugs.python.org/file12303/issue4580ws.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Copy & paste from python-dev post: The problem with memoryview appears to be related to the way it calculates its own length (since that is the check that is failing when the view blows up): >>> a = array('i', range(10)) >>> m = memoryview(a)

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Please, can you provide a patch that does not change whitespace everywhere? Even if these files use indentation inconsistently; the patch will be smaller and much easier to proofread. (I vaguely remember a document saying that it's bett

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +teoliphant ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mail

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Here is patch, using the "small storage at the end of Py_buffer" idea. It adds a lot of unit tests as well. -- keywords: +needs review, patch stage: test needed -> patch review Added file: http://bugs.python.org/file12293/issue4580.pa

[issue4580] slicing of memoryviews when itemsize != 1 is wrong

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: The problem is with the `shape` member which doesn't get recalculated as it should when instantiating a memoryview slice: >>> a = array('i', range(10)) >>> m = memoryview(a)[2:8] >>> a array('i', [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) >>> m[:] = a