On 01/06/2013 11:16 AM, Nathaniel Smith wrote:
> On 6 Jan 2013 07:59, "Dag Sverre Seljebotn" <d.s.seljebotn@astro.uio.no> <mailto:d.s.seljebotn@astro.uio.no>> wrote:
> > 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.
>> I agree it's complicated, but all the complications and options already
> exist - they're just split across two similar-but-not-quite-identical
> sets of data types.
>> > 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.
>> Not sure what you mean here. We know that whatever object a[0] returns
> is going to have scalar behaviour. Right now we have two totally
> different implementations of scalars. I'm not suggesting changing any
> (or hardly any) existing behaviour, just that we switch which
> implementation of that behavior we use.
In that case, how about not changing += for READONLY but instead have a
new ISSCALAR flag for that? I.e. semantics stay mostly as today, it's
just about removing those 10,000 lines of C code.
> I actually wrote that email as kind of amusing exercise in "what
> if...?", but even after sleeping on it I'm still not thinking of any
> terrible downsides...
I should say that I am really happy with the direction it is taking though.
(I wish I understood why using Python floats and ints is so horrible
though, but I've probably not written enough library NumPy code that
needs to consider all ndims and dtypes, just final-end-user-code where
the array vs. scalar distinction is more clear.)
Dag Sverre