seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Wed, May 16, 2018 at 10:06 AM, bartc <bc at freeuk.com> wrote:
> 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.

Sure, but that wasn't the example. The macro possibility is a good
point, but that's technically the C preprocessor, not the C language
itself.