Keyword same in right hand side of assignments (rev)
Thank you very much for correctly remarking that the "definition" I formulated contradicts the examples I gave and is therefore utterly inadecuate:
What I would like is to extend the augmented assignment and make it easy to understand for naive readers. I hope the following literary definition is consistent enough to convey the correct meaning: "whenever it is possible, modify the target IN PLACE according to the right hand side expression. If it is not possible to do such a thing, substitute the target object with an object that is build according to the right hand side expression and subsequently deleted" The following examples should be correct: "xx = same + 5" synonymous with "xx += 5" "value = 2*same + 5" synonymous with "value =*2; value +=5" "switch = 1 - same" synonymous with "switch *-1; switch +=1" "lst = same + [5,6]" synonymous with "lst += [5,6]" "lst[2] = 1/same" synonymous with "lst[2] **=-1" The following examples would be extensions: "lst = [5,6] + same" synonymous with "lst.reverse(); lst.extend([6,5]); lst.reverse()" "inmutable = same*(same+1)" synonymous with "unused=inmutable+1; inmutable*=unused; del unused" There seems to be no really simple expression for the above extensions, and I take that as an indication that the proposed feature could be quite useful.
On Tue, Mar 17, 2009 at 9:23 AM, <hwpuschm@yahoo.de> wrote:
I once wrote a blog post on how an expression like "N = N + 1" was confusing to beginners, so I'm sympathetic with the underlying idea. (http://aroberge.blogspot.com/2005/05/n-n-1.html Note that there are much better explanations for naming objects in Python than this old post I wrote.) However, I am -1 on this proposal. IMO, it decreases readability and achieves very little in terms of clearing up the confusion. Quick test: which is the easier to read and get right? n = same + 1 n = sane + 1 n = n + 1 André
Andre Roberge wrote:
I believe that as soon as the left-hand side stops being a simple variable and it is used in non-trivial expressions on the right-hand side, using the keyword would help clarify the intent. What I mean is that the examples you should be looking at are more like: A[n+1] = same*same + 1 B[2*j].foo = frobnicate(same, same+1) ... If you try expanding these into current python with minimal change in semantics you will end up with something like _1 = n+1 _2 = A[_1] A[_1] = _2*_2 + 1 del _1 del _2 _1 = B[2*j] _2 = _1.foo _1.foo = frobnicate(_2, _2+1) del _1 del _2 which is much less readable. I still think that the cost of a new keyword is probably too high a price to pay, but I like the idea. Jacob
On Wed, 18 Mar 2009 12:21:46 am Jacob Holm wrote:
Of course it is, because it's obfuscated. What's with the leading underscore names? Inside a function, they're not accessible to outside callers, so the notion of "private" and "public" doesn't apply, and in module-level code you delete them at the end, so they won't be imported because they no longer exist. (BTW, there's no need to delete the names one at a time. "del _1, _2" does what you want.) What's wrong with the clear, simple and obvious? A[n+1] = A[n+1]**2 + 1 If you really care about calculating n+1 twice then just use a meaningful name instead of an obfuscated name. This clarifies the intent of the code, instead of hiding it: index = n+1 # or even just i A[index] = A[index]**2 + 1 Likewise: tmp = B[2*j].foo B[2*j].foo = frobnicate(tmp, tmp+1) Or any combination of standard idioms. If you really insist, you can even delete the temporary names afterwards, but why would you bother inside a function? -- Steven D'Aprano
Steven D'Aprano wrote:
What is wrong is that it computes (n+1) twice, and it uses a different operator to avoid doing the __getitem__ twice. The whole point of the exercise was to get as close as possible to what I think the expression using "same" should mean. I tried to follow the common style for that kind of expansion as seen elsewhere on this list to make that clear. Obviously I failed. Jacob
Jacob Holm wrote:
Unless in a very tight loop, I see no reason why computing n+1 and __getitem__ twice is a problem. And using temporary variable is sufficiently clear enough unless your temporary variable's name starts with _.
On Tue, Mar 17, 2009 at 13:23, <hwpuschm@yahoo.de> wrote:
"lst = [5,6] + same" synonymous with "lst.reverse(); lst.extend([6,5]); lst.reverse()"
What about: lst = x + same ? -- Marcin Kowalczyk qrczak@knm.org.pl http://qrnik.knm.org.pl/~qrczak/
On Tue, 17 Mar 2009 11:23:23 pm hwpuschm@yahoo.de wrote:
Instead of the proposed "lst = [5,6] + same" or the obfuscated "lst.reverse(); lst.extend([6,5]); lst.reverse()", what about this simple assignment? lst = [5, 6] + lst Instead of the proposed "inmutable = same*(same+1)" or the obfuscated "unused=inmutable+1; inmutable*=unused; del unused", what about the simple: inmutable = inmutable*(inmutable+1) Since your claimed intention is to make it easy for naive users, why replace the standard idiom: xx += 5 with an assignment containing a mysterious "same"? Many of those naive users will surely assume "same" is a variable name, not a magic keyword, and spend much time looking for where it is assigned. I predict that if your idea goes ahead, we'll get dozens of questions "I can't find where the variable same gets its value from", and we'll have to explain that it is a magic variable that gets its value from the left hand side of the assignment. One last question -- what should happen here? x, y, z = (same, same+1, same+2) -- Steven D'Aprano
Steven D'Aprano wrote:
One last question -- what should happen here?
x, y, z = (same, same+1, same+2)
Obviously a typeerror, as you cannot add one or two to a tuple... :) But the same question for the statement x, y, z = (same, foo(same), bar(same)) has a simple obvious anwer (at least to my eyes). It should be equivalent to: tmp = x, y, z z, y, z = (tmp, foo(tmp), bar(tmp)) However, On rereading the proposal(s), I can see that all the operations using same are supposedly defined in terms of augmented assignment operators which really doesn't make any sense to me. (Augmented assignment is one of the very few things in python I find really unclean. I know practicality beats purity and all that, but it just doesn't sit right with me). It is quite possible that I have been interpreting this whole idea differently than the original author intended. If so, I apologize for the confusion. In any case I am at best -0.5 on it, because the benefit does not outweigh the cost of adding a new keyword. Jacob
On Tue, Mar 17, 2009 at 9:23 AM, <hwpuschm@yahoo.de> wrote:
I once wrote a blog post on how an expression like "N = N + 1" was confusing to beginners, so I'm sympathetic with the underlying idea. (http://aroberge.blogspot.com/2005/05/n-n-1.html Note that there are much better explanations for naming objects in Python than this old post I wrote.) However, I am -1 on this proposal. IMO, it decreases readability and achieves very little in terms of clearing up the confusion. Quick test: which is the easier to read and get right? n = same + 1 n = sane + 1 n = n + 1 André
Andre Roberge wrote:
I believe that as soon as the left-hand side stops being a simple variable and it is used in non-trivial expressions on the right-hand side, using the keyword would help clarify the intent. What I mean is that the examples you should be looking at are more like: A[n+1] = same*same + 1 B[2*j].foo = frobnicate(same, same+1) ... If you try expanding these into current python with minimal change in semantics you will end up with something like _1 = n+1 _2 = A[_1] A[_1] = _2*_2 + 1 del _1 del _2 _1 = B[2*j] _2 = _1.foo _1.foo = frobnicate(_2, _2+1) del _1 del _2 which is much less readable. I still think that the cost of a new keyword is probably too high a price to pay, but I like the idea. Jacob
On Wed, 18 Mar 2009 12:21:46 am Jacob Holm wrote:
Of course it is, because it's obfuscated. What's with the leading underscore names? Inside a function, they're not accessible to outside callers, so the notion of "private" and "public" doesn't apply, and in module-level code you delete them at the end, so they won't be imported because they no longer exist. (BTW, there's no need to delete the names one at a time. "del _1, _2" does what you want.) What's wrong with the clear, simple and obvious? A[n+1] = A[n+1]**2 + 1 If you really care about calculating n+1 twice then just use a meaningful name instead of an obfuscated name. This clarifies the intent of the code, instead of hiding it: index = n+1 # or even just i A[index] = A[index]**2 + 1 Likewise: tmp = B[2*j].foo B[2*j].foo = frobnicate(tmp, tmp+1) Or any combination of standard idioms. If you really insist, you can even delete the temporary names afterwards, but why would you bother inside a function? -- Steven D'Aprano
Steven D'Aprano wrote:
What is wrong is that it computes (n+1) twice, and it uses a different operator to avoid doing the __getitem__ twice. The whole point of the exercise was to get as close as possible to what I think the expression using "same" should mean. I tried to follow the common style for that kind of expansion as seen elsewhere on this list to make that clear. Obviously I failed. Jacob
Jacob Holm wrote:
Unless in a very tight loop, I see no reason why computing n+1 and __getitem__ twice is a problem. And using temporary variable is sufficiently clear enough unless your temporary variable's name starts with _.
On Tue, Mar 17, 2009 at 13:23, <hwpuschm@yahoo.de> wrote:
"lst = [5,6] + same" synonymous with "lst.reverse(); lst.extend([6,5]); lst.reverse()"
What about: lst = x + same ? -- Marcin Kowalczyk qrczak@knm.org.pl http://qrnik.knm.org.pl/~qrczak/
On Tue, 17 Mar 2009 11:23:23 pm hwpuschm@yahoo.de wrote:
Instead of the proposed "lst = [5,6] + same" or the obfuscated "lst.reverse(); lst.extend([6,5]); lst.reverse()", what about this simple assignment? lst = [5, 6] + lst Instead of the proposed "inmutable = same*(same+1)" or the obfuscated "unused=inmutable+1; inmutable*=unused; del unused", what about the simple: inmutable = inmutable*(inmutable+1) Since your claimed intention is to make it easy for naive users, why replace the standard idiom: xx += 5 with an assignment containing a mysterious "same"? Many of those naive users will surely assume "same" is a variable name, not a magic keyword, and spend much time looking for where it is assigned. I predict that if your idea goes ahead, we'll get dozens of questions "I can't find where the variable same gets its value from", and we'll have to explain that it is a magic variable that gets its value from the left hand side of the assignment. One last question -- what should happen here? x, y, z = (same, same+1, same+2) -- Steven D'Aprano
Steven D'Aprano wrote:
One last question -- what should happen here?
x, y, z = (same, same+1, same+2)
Obviously a typeerror, as you cannot add one or two to a tuple... :) But the same question for the statement x, y, z = (same, foo(same), bar(same)) has a simple obvious anwer (at least to my eyes). It should be equivalent to: tmp = x, y, z z, y, z = (tmp, foo(tmp), bar(tmp)) However, On rereading the proposal(s), I can see that all the operations using same are supposedly defined in terms of augmented assignment operators which really doesn't make any sense to me. (Augmented assignment is one of the very few things in python I find really unclean. I know practicality beats purity and all that, but it just doesn't sit right with me). It is quite possible that I have been interpreting this whole idea differently than the original author intended. If so, I apologize for the confusion. In any case I am at best -0.5 on it, because the benefit does not outweigh the cost of adding a new keyword. Jacob
participants (6)
-
Andre Roberge -
hwpuschm＠yahoo.de -
Jacob Holm -
Lie Ryan -
Marcin 'Qrczak' Kowalczyk -
Steven D'Aprano