seeking deeper (language theory) reason behind Python design choice

Wed May 16 12:06:26 EDT 2018

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