seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Tue, 08 May 2018 22:48:52 -0500, Python wrote:

> On Tue, May 08, 2018 at 12:45:29AM +0000, Steven D'Aprano wrote:
>> Currently, the real reason is that lambda expressions are limited to a
>> single expression as the body of the function, and binding operations
>> in Python are statements.
> 
> ...which begs the question, why shouldn't assignments be expressions, as
> they are in many other languages?  TBH this is one of the few things
> about Python that I dislike.

No, it raises the question :-) Begging the question means to assume the 
answer to the same question you are asking.

As Chris already pointed out, there is a PEP in progress at the moment 
aimed at allowing assignment expressions (PEP 572). It is very 
controversial, but Guido appears to be in favour of it (as I am, although 
not necessarily in its current form). There's about a bazillion emails on 
the Python-Ideas and Python-Dev mailing lists arguing about it.

(Oh, and it goes *all the way back to February*.)

In the very earliest versions of Python, like 0.1, there was only a 
single = operator that was used for both equals and assignment, but that 
was changed by the first official 1.0 release. I don't know if that 
change was driven by personal preference (Guido just liked it better), 
bad experiences with bugs, or what.

But by the time 1.4 came around, Guido had settled on a clean separation 
between statements and expressions as part of Python's design.

That separation has gradually weakened over the years, with the addition 
of the ternary if operator and comprehensions, but it is still an 
important part of Python's design. You might find something on Guido's 
blogs or his various essays:

http://neopythonic.blogspot.com.au/

https://www.artima.com/weblogs/index.jsp?blogger=guido

https://legacy.python.org/doc/essays/


but I don't have time to go trawling the blogs for this.

It might simply be that Guido (like many people) considered assignment to 
fundamentally be an imperative command, not an expression.

Another reason is something Nick Coghlan (re-)discovered during the 
discussions for PEP 572, namely that if you allow the full, unrestricted 
assignment targets as an expression, the code is ambiguous or at least 
hard to understand the intent. That's why PEP 572 has limited assignments 
to just plain names, and not arbitrary assignment targets. Possibly Guido 
recognised this way back in Python 0.x as well.


>> since = in a statement on its own is not dangerous. People *almost
>> never* intend to write == for the side-effects only:
> 
> Seriously?  I do this--not every day, but more than occasionally, not
> just in Python.
> 
>     flag = (spam == arg)

Of course we all do that, but it is nothing like what I said. I even gave 
fully-commented sample code, which you appear to have missed:

    # don't care whether they are actually equal or not
    # just want to call the __eq__ method for its side-effects
    spam == arg + 1

I bet you never, ever, ever call == for the side-effects, throwing away 
the result of the comparison without using it or looking at it in any 
way. In many languages, such a comparison cannot even have side-effects, 
so it would be useless dead code.


>>     # don't care whether they are actually equal or not 
>>     # just want to call the __eq__ method for its side-effects
>>     spam == arg + 1
>> 
>> Since that never happens in real life, there's no risk of accidentally
>> writing "spam = arg + 1" when you wanted "spam == arg + 1".
> 
> I've always felt that this mentality was insulting to the programmer:
> "You're too stupid to get this right."  Sure, I've created that bug in
> other languages (or rather its inverse) but not since college.  You make
> it a few times, you go nuts debugging it, you learn what it is, you
> never do it again.

And fortunately we don't have to deal with a steady stream of new 
programmers learning the language and making newbie errors, right?

If all programmers were as awesome as you and never made typos, the world 
would be a better place. But we know from experience that even 
experienced C programmers can make this mistake by accident.

Or deliberately:

https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-
of-2003/

or if that URL wraps: https://tinyurl.com/jpvbtua


Of course we all make mistakes, but some features and syntax are bug 
magnets: they *encourage* errors rather than discourage them. Anyone can 
mistype "flga" when they meant "flag", but the use of real words 
discourages that error since the reader can see that "flga" looks weird. 
But == and = are so similar that not only is it an easy typo to make, but 
its a hard typo to spot without a close, careful reading.


-- 
Steve