> 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 <pyt...@mrabarnett.plus.com> 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/
