Re: [Python-ideas] Add .= as a method return value assignment operator
On Fri, Sep 28, 2018 at 6:56 PM Jonathan Fine wrote: > Finally, I note > > >>> a = 2 > >>> a **= 3 > >>> a > 8 > ? Yes? That's what 2 ** 3 is, so that's what I would expect. All other augmented assignment operators take an assignment target on the left and a (single) value on the right. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
Summary: I recast an example in a more abstract form.
Steve D'Aprano wrote:
> Think about a more complex assignment:
>text .= encode(spam) + str(eggs)
I find this example instructive. I hope the following is also instructive:
$ python3
>>> obj += incr
NameError: name 'obj' is not defined
>>> obj = object()
>>> obj += incr
NameError: name 'incr' is not defined
>>> incr = 1
>>> obj += incr
TypeError: unsupported operand type(s) for +=: 'object' and 'int'
>>> incr = object()
>>> obj += incr
TypeError: unsupported operand type(s) for +=: 'object' and 'object'
>>> obj += [] + ()
TypeError: can only concatenate list (not "tuple") to list
To me this shows that
LHS += RHS
works as follows:
1. Evaluate the LHS (as an assignable object).
2. Evaluate the RHS (as a value).
and then some more steps, not covered in my example.
As syntax the compound symbols '+=' and '.=' are similar. But in
semantics, '+=' does and '.=' does not have an evaluation of the RHS
as an expression. This is, in abstract terms, the origin of Steve's
example. Someone else has noted that '+=' and its variants are focused
on numeric operations, such as addition.
This shows, to me, that the simplification provided by use cases such as
text = text.replace("foo","bar")
has to be compared to the complexity introduced by
text .= encode(spam) + str(eggs)
In other words, I've restated Steve's example, in a more abstract
form. I hope it helps to have another way to look at this example.
Finally, I note
>>> a = 2
>>> a **= 3
>>> a
8
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
On Fri, Sep 28, 2018 at 05:34:58PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >Think about a more complex assignment: > > > >text .= encode(spam) + str(eggs) > > I think the only sane thing would be to disallow that, and > require the RHS to have the form of a function call, which is > always interpreted as a method of the LHS. You obviously have a different idea of what is "sane" than I do :-) But okay, so we cripple the RHS so that it can only be a single method call. So useful things like these are out: target .= method(arg) or default target .= foo(arg) if condition else bar(arg) and even target .= method(args) + 1 making the syntax pure sugar for target = target.method(args) and absolutely nothing else. I think that's the sort of thing which gives syntactic sugar a bad name. The one positive I can see is that if the target is a compound expression, it could be evaluated once only: spam[0](x, y, z).eggs['cheese'].aardvark .= method(args) I suppose if I wrote a lot of code like that, aside from (probably?) violating the Law of Demeter, I might like this syntax because it avoids repeating a long compound target. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
I had the number 4 in mind Though I think your idea is way better, as it's more flexible and less confusing On Fri, Sep 28, 2018, 10:33 Brice Parent wrote: > > Le 27/09/2018 à 12:48, Ken Hilton a écrit : > > Hi Jasper, > This seems like a great idea! It looks so much cleaner, too. > > Would there be a dunder method handling this? Or since it's explicitly > just a syntax for "obj = obj.method()" is that not necessary? > My only qualm is that this might get PHP users confused; that's really not > an issue, though, since Python is not PHP. > > Anyway, I fully support this idea. > > What would the following evaluate to? > a .= b + c(d) > > 1: a = a.b + a.c(a.d) # everything is prepended an "a." > it means we dn't have access to any external elements, making the > functionality only useful in a few cases > > 2: a = a.b + a.c(d) # every first level element (if that means something) > is prepended an "a." > We still lose some of the ability to access anything outside of `a`, but a > bit less than in #1. The effort to understand the line as grown a bit, > though. > > 3: a = a.(b + c(d)) # everything is evaluated, and an "a." is prepended > to that result > (the same way `a *= 2 + 3` is equivalent to `a *= 5`) > I believe in most cases, this wouldn't mean anything to evaluate `b + > c(d)` on their own, and expect a return that can be used as an attribute of > `a`. > > 4: a = a.b + c(d) # "a." is prepended to the first element after the `=` > It is probably quite easy to read and understand, but it removes the > transitivity of the operators we have on the right, and is a bit limiting. > > 5: SyntaxError: Can only use the [whatever the name] augmented operator > with a single expression > Why not, it's a bit limiting, but is clear enough to me. > > Maybe, a simpler thing to do for this problem would be to make something > like this: > a = .b(5) + c(.d) + 3 > being the equivalent of > a = a.b(5) + c(a.d) + 3 > > I don't see any ambiguity anymore, it shortens the code a lot, and I guess > it wouldn't be hard for the compiler to recompose the line as a first > parsing step, and create the same AST with both syntaxes. > ___ > 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/
Re: [Python-ideas] Add .= as a method return value assignment operator
Le 27/09/2018 à 12:48, Ken Hilton a écrit : Hi Jasper, This seems like a great idea! It looks so much cleaner, too. Would there be a dunder method handling this? Or since it's explicitly just a syntax for "obj = obj.method()" is that not necessary? My only qualm is that this might get PHP users confused; that's really not an issue, though, since Python is not PHP. Anyway, I fully support this idea. What would the following evaluate to? a .= b + c(d) 1: a = a.b + a.c(a.d) # everything is prepended an "a." it means we dn't have access to any external elements, making the functionality only useful in a few cases 2: a = a.b + a.c(d) # every first level element (if that means something) is prepended an "a." We still lose some of the ability to access anything outside of `a`, but a bit less than in #1. The effort to understand the line as grown a bit, though. 3: a = a.(b + c(d)) # everything is evaluated, and an "a." is prepended to that result (the same way `a *= 2 + 3` is equivalent to `a *= 5`) I believe in most cases, this wouldn't mean anything to evaluate `b + c(d)` on their own, and expect a return that can be used as an attribute of `a`. 4: a = a.b + c(d) # "a." is prepended to the first element after the `=` It is probably quite easy to read and understand, but it removes the transitivity of the operators we have on the right, and is a bit limiting. 5: SyntaxError: Can only use the [whatever the name] augmented operator with a single expression Why not, it's a bit limiting, but is clear enough to me. Maybe, a simpler thing to do for this problem would be to make something like this: a = .b(5) + c(.d) + 3 being the equivalent of a = a.b(5) + c(a.d) + 3 I don't see any ambiguity anymore, it shortens the code a lot, and I guess it wouldn't be hard for the compiler to recompose the line as a first parsing step, and create the same AST with both syntaxes. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
Steven D'Aprano wrote: Think about a more complex assignment: text .= encode(spam) + str(eggs) I think the only sane thing would be to disallow that, and require the RHS to have the form of a function call, which is always interpreted as a method of the LHS. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
On 2018-09-27 03:48, Ken Hilton wrote: Would there be a dunder method handling this? Or since it's explicitly just a syntax for "obj = obj.method()" is that not necessary? My only qualm is that this might get PHP users confused; that's really not an issue, though, since Python is not PHP. I'm opposed to this idea, precisely because there's no way to make a dunder for it. Exiting augmented assignment operators work like this: "LHS op= RHS" means "LHS = LHS.__iop__(RHS)" (where iop is iadd, isub, etc.). This can't work for a dot operator. If "LHS .= RHS" is supposed to mean "LHS = LHS.RHS", then what is the argument that is going to be passed to the dunder method? The proposed .= syntax is using the RHS as the *name* of the attribute to be looked up, but for all existing augmented assignments, the RHS is the *value* to be operated on. As others pointed out elsewhere in the thread, the problem is compounded if there are multiple terms in the RHS. What does "this .= that + other" mean? What would be the argument passed to the dunder function? Is the name of the relevant attribute supposed to be taken from "that" or "other" or from the result of evaluating "that + other"? I like the consistency of the existing augmented assignment operations; they are just all syntactic sugar for the same pattern: LHS = LHS.__iop__(RHS) . I'm opposed to the creation of things that look like augmented assignment but don't follow the same pattern, which is what this proposal does. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
On Thu, Sep 27, 2018 at 09:47:42PM -0400, James Lu wrote:
> > I agree that this adds ambiguity where we can't be sure whether text .=
> > encode('utf-8') is referring to the function or the method. We can infer
> > that it *ought* to be the method, and maybe even add a rule to force
> > that, but this works only for the simple cases. It is risky and error
> > prone in the hard cases.
>
> I think it would be a good idea to treat all global name lookups as
> lookups on the object on the LHS when you’re on the RHS of .=.
We would be innundated with questions and bug reports complaining that
# earlier...
argument = something()
# later on
myobj = MyClass()
myobj .= method(argument)
fails with
AttributeError: 'MyClass' object has no attribute 'argument'
and people would be right to complain. That rule would mean you couldn't
use builtins or module-level names on the right hand side of the .=
operator. I call that a huge misfeature.
> This behavior prevents the worst mistakes and makes it very clear what
> is happening.
Far from preventing mistakes, it would cause them, whenever somebody
intended to use a builtin or module-level object, and accidently got a
completely different attribute of the target object.
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
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'
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
On Thu, Sep 27, 2018 at 10:44:38PM +0300, Taavi Eomäe wrote:
> > Do you see how this creates an ambiguous situation?
>
> Name shadowing could create such ambiguous situations anyways even without
> the new operator?
How? Can you give an example?
Normally, there is no way for a bare name to shadow a dotted name, or
vice versa, since the dotted name always needs to be fully qualified. In
the example below, we can talk about "text.encode" which is always the
method, or "encode", which is always the function and never the method.
I agree that this adds ambiguity where we can't be sure whether text .=
encode('utf-8') is referring to the function or the method. We can infer
that it *ought* to be the method, and maybe even add a rule to force
that, but this works only for the simple cases. It is risky and error
prone in the hard cases.
Think about a more complex assignment:
text .= encode(spam) + str(eggs)
This could mean any of:
text.encode(spam) + text.str(eggs)
text.encode(spam) + str(eggs)
encode(spam) + text.str(eggs)
encode(spam) + str(eggs)
In a statically typed language, the compiler could work out what is
needed at compile-time (it knows that text.str doesn't exist) and either
resolve any such ambiguities or refuse to compile. But in a dynamic
language like Python, you can't tell whether text.str exists or not
until you try it.
So this proposal suffers from the same problems as Pascal-style "with"
blocks, which are a FAQ:
https://docs.python.org/3/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
[...]
> > On 2018-09-27 14:13, Calvin Spealman wrote:
> > > Absolutely -1 on this. Consider the following example:
> > >
> > > def encode(s, *args):
> > > """Force UTF 8 no matter what!"""
> > > return s.encode('utf8')
> > >
> > > text = "Hello, there!"
> > > text .= encode('latin1')
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
> 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
wrote:
> 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/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
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/
[Python-ideas] Add .= as a method return value assignment operator
> 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?
It would not call randrange twice. Consider existing Python behavior:
def foo():
print("foo")
return 0
l = [7]
l[foo()] += 1
# output: "foo", but only once
print(l) # l == [8]
Sent from my iPhone
> On Sep 27, 2018, at 4:13 PM, Chris Angelico wrote:
>
> 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?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
On Wed, Sep 26, 2018 at 9:14 PM Jasper Rebane wrote:
> 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
> Do you see how this creates an ambiguous situation?
Name shadowing could create such ambiguous situations anyways even without
the new operator?
> In my opinion, it goes against the notion that explicit is better than
implicit.
By that logic all operation-assign operations violate that rule (e.g. "-=",
"+=" etc.). I honestly don't feel how this feels any less explicit that
what already exists in the language.
> Assumes that every function returns a value or perhaps implies purity.
So does `obj = obj.func(args)` or I've misunderstood you?
I like the operator, so +1, though I feel it could be even more useful if
it allowed accessing class members, `obj = obj.id` being equivalent to `obj
.= id`, what do you think?
On Thu, Sep 27, 2018 at 8:05 PM MRAB wrote:
> On 2018-09-27 14:13, Calvin Spealman wrote:
> > Absolutely -1 on this. Consider the following example:
> >
> > def encode(s, *args):
> > """Force UTF 8 no matter what!"""
> > return s.encode('utf8')
> >
> > text = "Hello, there!"
> > text .= encode('latin1')
> >
> > Do you see how this creates an ambiguous situation? Implicit attribute
> > lookup like this is really confusing. It reminds me of the old `with`
> > construct in javascript that is basically forbidden now, because it
> > created the same situation.
> >
> I don't believe it's ambiguous. The intention is that:
>
> text .= encode('latin1')
>
> would be equivalent to:
>
> text = text.encode('latin1')
>
> However, I'm also -1 on it.
>
> [snip]
> ___
> 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/
Re: [Python-ideas] Add .= as a method return value assignment operator
On 2018-09-27 14:13, Calvin Spealman wrote:
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation? Implicit attribute
lookup like this is really confusing. It reminds me of the old `with`
construct in javascript that is basically forbidden now, because it
created the same situation.
I don't believe it's ambiguous. The intention is that:
text .= encode('latin1')
would be equivalent to:
text = text.encode('latin1')
However, I'm also -1 on it.
[snip]
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
I believe Calvin is right. .= Assumes that every function returns a value or
perhaps implies purity. In my opinion, it goes against the notion that explicit
is better than implicit.
Stelios Tymvios
> On 27 Sep 2018, at 4:13 PM, Calvin Spealman wrote:
>
> Absolutely -1 on this. Consider the following example:
>
> def encode(s, *args):
> """Force UTF 8 no matter what!"""
> return s.encode('utf8')
>
> text = "Hello, there!"
> text .= encode('latin1')
>
> Do you see how this creates an ambiguous situation? Implicit attribute lookup
> like this is really confusing. It reminds me of the old `with` construct in
> javascript that is basically forbidden now, because it created the same
> situation.
>
>> On Thu, Sep 27, 2018 at 6:49 AM Ken Hilton wrote:
>> Hi Jasper,
>> This seems like a great idea! It looks so much cleaner, too.
>>
>> Would there be a dunder method handling this? Or since it's explicitly just
>> a syntax for "obj = obj.method()" is that not necessary?
>> My only qualm is that this might get PHP users confused; that's really not
>> an issue, though, since Python is not PHP.
>>
>> Anyway, I fully support this idea.
>>
>> Sincerely,
>> Ken Hilton;
>> ___
>> 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/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add .= as a method return value assignment operator
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation? Implicit attribute
lookup like this is really confusing. It reminds me of the old `with`
construct in javascript that is basically forbidden now, because it created
the same situation.
On Thu, Sep 27, 2018 at 6:49 AM Ken Hilton wrote:
> Hi Jasper,
> This seems like a great idea! It looks so much cleaner, too.
>
> Would there be a dunder method handling this? Or since it's explicitly
> just a syntax for "obj = obj.method()" is that not necessary?
> My only qualm is that this might get PHP users confused; that's really not
> an issue, though, since Python is not PHP.
>
> Anyway, I fully support this idea.
>
> Sincerely,
> Ken Hilton;
> ___
> 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/
Re: [Python-ideas] Add .= as a method return value assignment operator
Hi Jasper, This seems like a great idea! It looks so much cleaner, too. Would there be a dunder method handling this? Or since it's explicitly just a syntax for "obj = obj.method()" is that not necessary? My only qualm is that this might get PHP users confused; that's really not an issue, though, since Python is not PHP. Anyway, I fully support this idea. Sincerely, Ken Hilton; ___ 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] 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
