seeking deeper (language theory) reason behind Python design choice

[bartc]

On 16/05/2018 16:09, Ian Kelly wrote:
> On Tue, May 15, 2018, 6:36 PM bartc <bc at freeuk.com> wrote:
> 
>> On 16/05/2018 01:04, Steven D'Aprano wrote:
>>
>>> I'm not a C coder, but I think that specific example would be immune to
>>> the bug we are discussing, since (I think) you can't chain assignments in
>>> C. Am I right?
>>
>> Assignments can be chained in C (with right-to-left precedence) as can
>> augmented assignments (+= and so on).
>>
> 
> Yes, but not in the particular example that Steven was referring to, which
> you elided from your quoting.

I was responding to the chained assignment bit:

  a = b = c = d = x;

is allowed, but (depending on implementation details), the first = might 
be a different kind of assignment from the other three.

> open(...) is not a valid LHS for assignment.

The LHS needs to be an lvalue. A function result by itself won't be. 
open() would need to be a macro that expands to an lvalue, or used like 
this when open() returns a pointer:

    a = *open() = x;

So it only needs an extra * (subject to the correct types of everything 
involved) for both these "=" to be plausible.

-- 
bartc