[Python-ideas] Add .= as a method return value assignment operator

[James Lu]

> 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 .=.

This behavior prevents the worst mistakes and makes it very clear what is happening.

Sent from my iPhone

> On Sep 27, 2018, at 8:03 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/