Non-writeable default for numpy.ndarray
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
Hello, Is the next a bug a feature? In [102]: f4=numpy.ndarray(buffer="a\x00b"*4, dtype="f4", shape=3) In [103]: f4 Out[103]: array([ 2.60561966e+20, 8.94319890e-39, 5.92050103e+20], dtype=float32) In [104]: f4[2] = 2 --------------------------------------------------------------------------- <type 'exceptions.RuntimeError'> Traceback (most recent call last) /home/faltet/python.nobackup/numpy/<ipython console> in <module>() <type 'exceptions.RuntimeError'>: array is not writeable In [105]: f4.flags.writeable = True In [106]: f4[2] = 2 In [107]: f4 Out[107]: array([ 2.60561966e+20, 8.94319890e-39, 2.00000000e+00], dtype=float32) i.e. in an array built from ndarray, the default is that it has to be read-only? --
![](https://secure.gravatar.com/avatar/5b2449484c19f8e037c5d9c71e429508.jpg?s=120&d=mm&r=g)
Francesc Altet wrote:
It's not that the it's being built from ndarray, it's that the buffer that you are passing it is read only. In fact, I'd argue that allowing the writeable flag to be set to True in this case is actually a bug. Consider this slightly modified example: >>> a = "12345"*4 >>> f4=numpy.ndarray(buffer=a, dtype="f4", shape=3) >>> f4[2] = 99 Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: array is not writeable >>> f4.flags.writeable = True >>> a '12345123451234512345' >>> f4.flags.writeable = True >>> f4[2] = 99 >>> a '12345123\x00\x00\xc6B34512345' The original, *immutable* string has been mutated. This could get you into real trouble in certain situations. -tim
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
El dv 29 de 09 del 2006 a les 16:27 -0600, en/na Travis Oliphant va escriure:
You are welcome, but actually the merit is more of the pytables test suite than mine :-) Travis, I've expressed publicly many times my gratitude to you, but I'm going to do so once more(so, be ready :-): I was absolutely thrilled that each and everyone of my bug reports were either solved or declared features in a matter of 1 or 2 days as maximum, and this is just *amazing* in a complex software like NumPy. I don't need to say it again (but will do): You have made of NumPy *the* reference of python array packages, and better that this, you have made this only in one year and a half! Definitely, I have come to the conclusion that you are not human, but rather a MONSTER! :-) Also thanks goes to Charles Harris, for implementing very fine-tuned sorting algorithms in both numpy and numarray packages. His work is very useful for us. Finally, and although not directly related with numpy, I'd like to express my gratitude and acknowledgement to David Cooke (and Tim Hochberg) for it's work on numexpr: it's a perfect complement to numpy in that it allows to accelerate even more many of the basic operations with arrays. All of you, and the rest of the numpy community are a first-class team, and this is why it makes me so happy to help you! --
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote:
It's actually intentional. Strings used as buffers are allowed to be writeable. This is an explicit design decision to allow pickles to load without making 2 copies of the memory. The pickled string that Python creates is used as the actual memory for loaded arrays. Now, I suppose it would be possible to still allow this but be more finnicky about when a string-used-as-the-memory can be set writeable (i.e. we are the only reference to it). But, this would be a fragile solution as well. My inclination is to just warn users not to use strings as buffers unless they know what they are doing. The fact that it is read-only by default is enough of a guard against "accidentally" altering a string you didn't want to alter. -Travis
![](https://secure.gravatar.com/avatar/5b2449484c19f8e037c5d9c71e429508.jpg?s=120&d=mm&r=g)
Francesc Altet wrote:
It's not that the it's being built from ndarray, it's that the buffer that you are passing it is read only. In fact, I'd argue that allowing the writeable flag to be set to True in this case is actually a bug. Consider this slightly modified example: >>> a = "12345"*4 >>> f4=numpy.ndarray(buffer=a, dtype="f4", shape=3) >>> f4[2] = 99 Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: array is not writeable >>> f4.flags.writeable = True >>> a '12345123451234512345' >>> f4.flags.writeable = True >>> f4[2] = 99 >>> a '12345123\x00\x00\xc6B34512345' The original, *immutable* string has been mutated. This could get you into real trouble in certain situations. -tim
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
El dv 29 de 09 del 2006 a les 16:27 -0600, en/na Travis Oliphant va escriure:
You are welcome, but actually the merit is more of the pytables test suite than mine :-) Travis, I've expressed publicly many times my gratitude to you, but I'm going to do so once more(so, be ready :-): I was absolutely thrilled that each and everyone of my bug reports were either solved or declared features in a matter of 1 or 2 days as maximum, and this is just *amazing* in a complex software like NumPy. I don't need to say it again (but will do): You have made of NumPy *the* reference of python array packages, and better that this, you have made this only in one year and a half! Definitely, I have come to the conclusion that you are not human, but rather a MONSTER! :-) Also thanks goes to Charles Harris, for implementing very fine-tuned sorting algorithms in both numpy and numarray packages. His work is very useful for us. Finally, and although not directly related with numpy, I'd like to express my gratitude and acknowledgement to David Cooke (and Tim Hochberg) for it's work on numexpr: it's a perfect complement to numpy in that it allows to accelerate even more many of the basic operations with arrays. All of you, and the rest of the numpy community are a first-class team, and this is why it makes me so happy to help you! --
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote:
It's actually intentional. Strings used as buffers are allowed to be writeable. This is an explicit design decision to allow pickles to load without making 2 copies of the memory. The pickled string that Python creates is used as the actual memory for loaded arrays. Now, I suppose it would be possible to still allow this but be more finnicky about when a string-used-as-the-memory can be set writeable (i.e. we are the only reference to it). But, this would be a fragile solution as well. My inclination is to just warn users not to use strings as buffers unless they know what they are doing. The fact that it is read-only by default is enough of a guard against "accidentally" altering a string you didn't want to alter. -Travis
participants (4)
-
Francesc Altet
-
Tim Hochberg
-
Travis Oliphant
-
Travis Oliphant