
On Feb 13 2015, Erik Bray <erik.m.bray-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Fri, Feb 13, 2015 at 6:22 PM, Nikolaus Rath <Nikolaus-BTH8mxji4b0@public.gmane.org> wrote:
Alexander Heger <python-ePO413wvQzY-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
As far as I was, and still am, concerned, & is the obvious and most natural operator for concatenation. [1, 2]+[3, 4] should return [4, 6], and sum(bunch of lists) should be a meaningless operation, like sum(bunch of HTTP servers). Or sum(bunch of dicts).
This only works if the items *can* be added. Dics should not make such an assumption. & is not a more natural operator, because, why would you then not just expect that [1, 2] & [3, 4] returns [1 & 2, 3 & 4] == [0 , 0] ? the same would be true for any operator you pick.
Which brings us back to the idea to introduce elementwise variants of any operator:
[1,2] .+ [3,4] == [1+3, 2+4] [1,2] + [3,4] == [1,2,3,4] [1,2] .& [3,4] == [1 & 3, 2 & 4] [1,2] & [3,4] == not (yet?) defined
As a regular numpy user, I'd be very happy about that too :-).
... except for the part where in Numpy ".+" and "+" and so one would
Parse error.
have to be identical, which would be no end of confusing especially when adding, say, a Numpy array and a list.
Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«