On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum wrote:
I know I shouldn't be posting in this thread, and I won't be there to read the responses, but here's what I thought would be cool.
As the 'lucky, lucky bastard' is probably standing before the altar about now, I'll send this to the dev-list instead. Not that I expect anyone *not* to be at the wedding, but I bet the rest is back sooner ;-)
x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" (an old Algol-68 naming convention; we could pick something better later but this will do for the explanation).
For immutable types, this is defined as
def __add_ab__(self, other): return self+other
For mutable types, this is defined as a self-mutating operation, e.g. for lists it could be
def __add_ab__(self, other): self.extend(other) return self
This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ? I had a chat with Michael about fixing up his patch to work all the way (it's currently a proof-of-concept-quick-hack that only works for builtin types) which prompted me to study Python's internals a bit closer. (I hope I dont sound too patronizing when I say I was impressed ;-) I'm curious what should happen with index-assignment and slice-assignment: x[y] += z x[:y] += z (Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.) Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ? Or would x[y] += z always call x[y].__add_item_ab__() and x[:y] create a new object, a slice of x, and call its __add_ab__() method ? Or would it try all of them, or more, until it gets a good result ? Or am I running ahead of things and should we wait for a working patch first ? :) If I suddenly grow a deep understanding of Python's internals (not ruled out, it's fairly obvious) and hack-up something that works before anyone else, I'll be sure to mail ;) oh-and-congratulations-to-Mrs.-van-Rossum-too-ly yr's, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> On Wed, May 31, 2000 at 11:49:57PM +0000, Guido van Rossum TW> wrote:
I know I shouldn't be posting in this thread, and I won't be there to read the responses, but here's what I thought would be cool.
x+=y is syntactic sugar for x=x.__add_ab__(y); the "ab" means "and becomes" (an old Algol-68 naming convention; we could pick something better later but this will do for the explanation).
[...] TW> This was what I had in mind, and was trying to explain. Does you TW> voicing your opinion mean someone (you ? someone else ?) is TW> working on this, or soon going to work on this ? I don't believe anyone at PythonLabs is working on this now, certainly not Guido or I. Jeremy
"JH" == Jeremy Hylton <jeremy@beopen.com> writes:
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> This was what I had in mind, and was trying to explain. Does TW> you voicing your opinion mean someone (you ? someone else ?) TW> is working on this, or soon going to work on this ? JH> I don't believe anyone at PythonLabs is working on this now, JH> certainly not Guido or I. I'm not tracking this either. -Barry
[posted & mailed] [Thomas Wouters, asking about Guido's sketch]
This was what I had in mind, and was trying to explain. Does you voicing your opinion mean someone (you ? someone else ?) is working on this, or soon going to work on this ?
It's the same scheme he sketched the last time he was provoked into writing about this <wink>, and that was at least a year ago.
... I'm curious what should happen with index-assignment and slice-assignment:
Nothing special! You're reading far too much into Guido's sketch -- it doesn't have all these convolutions. Try reading his msg again, but this time thinking like him too <wink>.
x[y] += z
temp1 = x # perhaps the first three are permuted, though temp2 = y temp3 = z temp1[temp2] = temp1[temp2].__add_ab__(temp3) And, yes, indexing is done twice (although "x" and "y" are evaluated only once each).
x[:y] += z
temp1 = x temp2 = y temp3 = z temp1[:temp2] = temp1[:temp2].__add_ab__(temp3) Similarly slicing is done twice.
(Obviously this wont make sense for a lot of types, or will be too un-obvious to include, but I can imagine matrix-types to happily add this.)
Every type is free to implement __add_ab__ or not, in whatever way it likes. But Python can't tell at compile-time which types do and don't implement it, so chances are great that doing x += y for x of a type that does not implement __add_ab__ will raise a runtime AttributeError.
Would this call x.__add_item_ab__(y, z) and x.__add_slice_ab__(0, y, z) ?
No. *All* instances of "+=" are mapped straightforwardly to __add_ab__. Context is irrelevent; indexing and slicing are not special cases (except to the extent that they are already ...).
Or would x[y] += z always call x[y].__add_item_ab__()
No.
and x[:y] create a new object, a slice of x
What x[:y] means is entirely up to the type of x, and has no connection to augmented assignment (except in that the author of the type may design both to work smoothly together).
and call its __add_ab__() method ?
__add_ab__ would be invoked on whatever x[:y] returns; whether that's "a new object" or not is x.__get_slice__'s choice to make.
Or would it try all of them, or more, until it gets a good result ?
No. It works or it doesn't.
Or am I running ahead of things and should we wait for a working patch first ? :)
No, you're running a few years behind things <wink>, and imagining complications Guido would never sign up for. and-now-the-spirits-must-rest-ly y'rs - tim
participants (4)
-
bwarsaw＠python.org -
Jeremy Hylton -
Thomas Wouters -
Tim Peters