[Python-ideas] Augmented assignment syntax for objects.

[Chris Angelico]

On Fri, Apr 28, 2017 at 4:57 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Fri, Apr 28, 2017 at 03:30:29PM +1000, Chris Angelico wrote:
>
>> > Obviously we can define syntax to do anything we like, but what is the
>> > logical connection between the syntax and the semantics? What part of
>> > "function parameter list" suggests "assign attributes to arbitrary
>> > objects"?
> [...]
>> What part of a 'for' loop suggests that you can do this?
>
> I'm not sure what "this" is supposed to do. You've written some
> obscure but perfectly legal Python code:
>
>> odds = [0]*10; evens = [0]*10
>> for idx, (odds if idx%2 else evens)[idx//2] in stuff:
>>     ...
>
> My guess is that "this" refers to the side-effect that assigning to a
> list item updates the list item. Um, yeah, it does. What's your point?
> Of course it does. That's what its supposed to do.
>
> Perhaps you think that there's something weird about using an arbitrary
> assignment target as the for-loop. I don't know why you think that's
> weird. Here's a simpler example:
>
> for obj.attr in seq:
>     ...
>
> Yes, its a bit unusual to do that, but its not weird. The assignment
> target for a loop is just an ordinary assignment target, and the
> assignment occurs during the execution of code, just like any other
> assignment that occurs inside the body of the function.
>
> What is weird is to have the function *declaration* have global side
> effects and perform assignments outside of the function. The parameter
> list is *not* a general assignment statement, it is a declaration of
> what local variables will be assigned to when you call the function.

Waaaaaait a minute. Since when is the *declaration* doing this? No no
no. In every proposal, it's been a part of the function's *execution*.
The original example was an __init__ function that does the exact same
thing as my for loop example: it first sets "self" to the first
parameter, and then sets some attributes on self. As you say:

> Um, yeah, it does. What's your point?
> Of course it does. That's what its supposed to do.

There is nothing surprising in it (although my example was
deliberately convoluted and a bad example of code). It's assignment,
pure and simple.

When you call a function, the values you pass to it get assigned to
the names provided in the declaration. No assignments happen at
declaration other than the function's own name. (I suppose you could
say that default argument values are "assigned" at that point, but I
prefer to say "collected", since they're basically assembled into a
tuple and slapped into an attribute on the function.)

>> Nothing whatsoever says that this is a good idea, but it's perfectly
>> legal, because the for loop is defined in terms of assignment. If this
>> were to be accepted (which, fwiw, I'm not actually advocating, but
>> IF), it would also be defined in terms of assignment.
>
> Why should it be defined in terms of general assignment? That's the
> point I'm making. While function sigs are a form of assignment, they're
> more of a declaration than an executable statement like the other
> binding statements. There's a superficial connection, but they really
> are quite different things.

There's a lot more similarities than you might think. For example,
both of these will create "spam" as a local name, shadowing the
global:

spam = 1
def func1(spam):
    print(spam)
def func2():
    spam = 2
    print(spam)

As will many other forms of assignment, like "import spam" or "with x
as spam:". Some forms are more restricted than others ("import"
requires a NAME, not an arbitrary expression), but they all behave the
same way with regard to global/nonlocal/local naming - you can "global
numpy; import numpy" inside a function to do a delayed import, for
instance.

> (For example: if you allow spam.foo as a parameter, that can call
> arbitrary Python code in spam.__setattr__, which assigning to foo as a
> parameter will not do.)

Sure, but that's a difference between simple name assignment and
item/attribute assignment, not a difference between function
parameters and other types of variables. Are you next going to point
out that you can't "import spam as foo[0]"? Or that importing is
somehow special because of this? No. It's still assignment, just one
with a restricted syntax.

>> You still
>> shouldn't be assigning to arbitrary objects, especially not randomly
>> rebinding module names, but it's easy to grok the assignment
>> equivalence.
>
> You need to speak to more beginners if you think the connection between
> spam.x and x is obvious:
>
>     def func(spam.x):
>         print(x)
>
> Where is x declared? It looks like there's a local spam.x which isn't
> used, and a global x that is. But that's completely wrong. Without the
> context of somebody telling you "this is syntax for magically assigning
> to self.attributes in the constructor", I believe this will be
> unfathomable to the average non-expert.

Not sure what you mean. By my reading, that's exactly correct - there
IS a global x that is being used here, although "local spam.x" is not
accurate. I wouldn't call that "completely wrong". And if you find
that confusing, let's look at importing.

os = "Linux"
path = "/tmp"
def func():
    import os.path
    print(path)

What's local and what's global? What name is actually bound by "import
os.path"? What if you said "import os.path as path"? "import os.path
as os"? Does all this confuse people? IMO it's *less* confusing if you
can simply say "this is equivalent to <parameter> = <argument>".

>> And yes, it WOULD reinstate the argument unpacking removed by PEP
>> 3113. So for this to go forward, the objections in that PEP would have
>> to be addressed.
>
> Nicely remembered :-)
>

I didn't remember the PEP number, but the Google is helpful :)

ChrisA