On 01/06/2013 10:41 AM, Sebastian Berg wrote: > On Sun, 2013-01-06 at 08:58 +0100, Dag Sverre Seljebotn wrote: >> On 01/05/2013 10:31 PM, Nathaniel Smith wrote: >>> On 5 Jan 2013 12:16, "Matthew Brett" <matthew.br...@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Following on from Nathaniel's explorations of the scalar - array >>>> casting rules, some resources on rank-0 arrays. >>>> > > <snip> > >>> Q: Yeah. I mean, I remember that seemed weird when I first learned >>> Python, but when have you ever felt the Python was really missing a >>> "character" type like C has? >> >> str is immutable which makes this a lot easier to deal with without >> getting confused. So basically you have: >> >> a[0:1] # read-write view >> a[[0]] # read-write copy >> a[0] # read-only view >> >> AND, += are allowed on all read-only arrays, they just transparently >> create a copy instead of doing the operation in-place. >> >> Try to enumerate all the fundamentally different things (if you count >> memory use/running time) that can happen for ndarrays a, b, and >> arbitrary x here: >> >> a += b[x] >> >> That's already quite a lot, your proposal adds even more options. It's >> certainly a lot more complicated than str. >> >> To me it all sounds like a lot of rules introduced just to have the >> result of a[0] be "kind of a scalar" without actually choosing that option. >> > > Yes, but I don't think there is an option to making the elements of an > array being immutable. Firstly if you switch normal python code to numpy > code you suddenly get numpy data types spilled into your code, and > mutable objects are simply very different (also true for code updating > to this new version). Do you expect: > > array = np.zeros(10, dtype=np.intp) > b = arr[5] > while condition: > # might change the array?! > b += 1 > # This would not be possible and break: > dictionary[b] = b**2 > > Because mutable objects are not hashable which important considering > that dictionaries are a very central data type, making an element return > mutable would be a bad idea.
Indeed, this would be completely crazy. I should have been more precise: I like the proposal, but also believe the additional complexity introduced have significant costs that must be considered. a) Making += behave differently for readonly arrays should be carefully considered. If I have a 10 GB read-only array, I prefer an error to a copy for +=. (One could use an ISSCALAR flag instead that only affected +=...) b) Things seems simpler since "indexing away the last index" is no longer a special case, it is always true for a.ndim > 0 that "a[i]" is a new array such that a[i].ndim == a.ndim - 1 But in exchange, a new special-case is introduced since READONLY is only set when ndim becomes 0, so it doesn't really help with the learning curve IMO. In some ways I believe the "scalar-indexing" special case is simpler for newcomers to understand, and is what people already assume, and that a "readonly-indexing" special case is more complicated. It's dangerous to have a library which people only use correctly by accident, so to speak, it's much better if what people think they see is how things are. (With respect to arr[5] returning a good old Python scalar for floats and ints -- Travis' example from 2002 is division, and at least that example is much less serious now with the introduction of the // operator in Python.) > One could argue about structured datatypes, but maybe then it should be > a datatype property whether its mutable or not, and even then the > element should probably be a copy (though I did not check what happens > here right now). Elements from arrays with structured dtypes are already mutable (*and*, at least until recently, could still be used as dict keys...). This was discussed on the list a couple of months back I think. Dag Sverre > >> BUT I should read up on that thread you posted on why that won't work, >> didn't have time yet... >> >> Dag Sverre >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
