Add .= as a method return value assignment operator
Hi, When using Python, I find myself often using assignment operators, like 'a += 1' instead of 'a = a + 1', which saves me a lot of time and hassle Unfortunately, this doesn't apply to methods, thus we have to write code like this: text = "foo" text = text.replace("foo","bar") # "bar" I propose that we should add '.=' as a method return value assignment operator so we could write the code like this instead: text = "foo" text .= replace("foo","bar") # "bar" This looks cleaner, saves time and makes debugging easier Here are a few more examples: text = " foo " text .= strip() # "foo" text = "foo bar" text .= split(" ") # ['foo', 'bar'] text = b'foo' text .= decode("UTF-8") # "foo" foo = {1,2,3} bar = {2,3,4} foo .= difference(bar) # {1} Rebane
On Wed, Sep 26, 2018 at 9:14 PM Jasper Rebane
When using Python, I find myself often using assignment operators, like 'a += 1' instead of 'a = a + 1', which saves me a lot of time and hassle
Unfortunately, this doesn't apply to methods, thus we have to write code like this: text = "foo" text = text.replace("foo","bar") # "bar"
I propose that we should add '.=' as a method return value assignment operator so we could write the code like this instead: text = "foo" text .= replace("foo","bar") # "bar" This looks cleaner, saves time and makes debugging easier
All the other augmented operators are of the form: target #= value with some sort of valid assignment target, and any value at all on the right hand side. You can take the value and put it in a variable, you can replace it with a function returning that value, etc, etc, etc, as it is simply a value. There's no difference between "x += 123" and "y = 123; x += y". (Putting it another way: "x *= y + z" is not equivalent to "x = x * y + z", but to "x = x * (y + z)".) With your proposed ".=" operator, it's quite different: the RHS is textually concatenated with the LHS. This creates odd edge cases. For example: items = ["foo", "bar", "quux"] items[randrange(3)] .= upper() Is this equivalent to: items[randrange(3)] = items[randrange(3)].upper() ? That would call randrange twice, potentially grabbing one element and dropping it into another slot. If it isn't equivalent to that, how is it defined? I'm sure something can be figured out that will satisfy the interpreter, but will it work for humans? ChrisA
As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are exceptions, for example all immutable types or some promotions
between numbers.
In your examples some cases imply that you are working on names, others
that you are working on objects. And as for me this ambiguity is not
solvable.
With kind regards,
-gdg
ср, 26 сент. 2018 г. в 14:14, Jasper Rebane
Hi,
When using Python, I find myself often using assignment operators, like 'a += 1' instead of 'a = a + 1', which saves me a lot of time and hassle
Unfortunately, this doesn't apply to methods, thus we have to write code like this: text = "foo" text = text.replace("foo","bar") # "bar"
I propose that we should add '.=' as a method return value assignment operator so we could write the code like this instead: text = "foo" text .= replace("foo","bar") # "bar" This looks cleaner, saves time and makes debugging easier
Here are a few more examples: text = " foo " text .= strip() # "foo"
text = "foo bar" text .= split(" ") # ['foo', 'bar']
text = b'foo' text .= decode("UTF-8") # "foo"
foo = {1,2,3} bar = {2,3,4} foo .= difference(bar) # {1}
Rebane _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
As I see it, you are mixing very different things. Augmented operators in Python work on objects, generally trying to mutate them in-place. So usually after these operations you have the same object (with the same type, with the same name and etc.) as before these operations. Of course there are exceptions, for example all immutable types or some promotions between numbers.
Yep.
a = (5, 2) a += (3, ) a (5, 2, 3)
In your examples some cases imply that you are working on names, others that you are working on objects. And as for me this ambiguity is not solvable.
example please? Show an ambiguous case. To me, it's always working on
names.
On Thu, Sep 27, 2018 at 5:32 PM Kirill Balunov
As I see it, you are mixing very different things. Augmented operators in Python work on objects, generally trying to mutate them in-place. So usually after these operations you have the same object (with the same type, with the same name and etc.) as before these operations. Of course there are exceptions, for example all immutable types or some promotions between numbers.
In your examples some cases imply that you are working on names, others that you are working on objects. And as for me this ambiguity is not solvable.
With kind regards, -gdg
ср, 26 сент. 2018 г. в 14:14, Jasper Rebane
: Hi,
When using Python, I find myself often using assignment operators, like 'a += 1' instead of 'a = a + 1', which saves me a lot of time and hassle
Unfortunately, this doesn't apply to methods, thus we have to write code like this: text = "foo" text = text.replace("foo","bar") # "bar"
I propose that we should add '.=' as a method return value assignment operator so we could write the code like this instead: text = "foo" text .= replace("foo","bar") # "bar" This looks cleaner, saves time and makes debugging easier
Here are a few more examples: text = " foo " text .= strip() # "foo"
text = "foo bar" text .= split(" ") # ['foo', 'bar']
text = b'foo' text .= decode("UTF-8") # "foo"
foo = {1,2,3} bar = {2,3,4} foo .= difference(bar) # {1}
Rebane _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
This seems like a fairly terrible idea. -100 from me. Python simply does not tends to chain methods for mutation of objects. A few libraries—e.g. Pandas—do this, but in those cases actual chaining is more idiomatic. This is very different from '+=' or '*=' or even '|=' where you pretty much expect to wind up with the same type of thing on the binding or mutation. Of course, you can define operators as you like, so it's not hard and fast, but it's usual. I.e. '+=' is unlikely to leave the current number domain, other than according to the regular numeric hierarchy. text = "foo"
text .= replace("foo","bar")
This one example is okay. But most are awful: text .= count('foo') text .= split(';') text .= find('bar') In all of those you jump around among various data types bound to 'text'
participants (5)
-
Chris Angelico
-
David Mertz
-
James Lu
-
Jasper Rebane
-
Kirill Balunov