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 -- https://mail.python.org/mailman/listinfo/python-list