Nathaniel Smith wrote > Actually, now that I think about it there is a much worse general version > of this problem, which probably kills the idea dead. Via the buffer > interface (among others), it is totally legal and encouraged to create > non-numpy views of numpy arrays. They'll check the flags once at creation > time, but after that they're free to write directly to the underlying > buffer whenever they please: > > a = np.ones(10) > a2 = memoryview(a) > a2[0] = 0 > # now what?
You could say that when you create a memoryview you set a to being non-mutablehash-able. Ideally you would want a C++ RAII-like/python with-block style implementation so that when the memoryview is destroyed the mutablehash-able-ness is reinstated (although I guess you would need a ref count of memoryviews to do that safely). I don't know how common memoryview is within numpy itself or whether it's only part of the extension API? If it's relatively rare, then given that this hashing thing could easily be designed to fail gracefully it would seem a shame not to implement it simply because of this issue...in my opinion of course! P.S. I had no idea about the view-local write-lock...that's rather a surprise. -- View this message in context: http://numpy-discussion.10968.n7.nabble.com/feature-request-increment-counter-on-write-check-tp41015p41023.html Sent from the Numpy-discussion mailing list archive at Nabble.com. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
