On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote: > Op 12-09-15 om 05:48 schreef Steven D'Aprano: >> I believe I already acknowledged that assignment-as-expression was fine >> if it avoided the = versus == error, from the perspective of avoiding >> errors. But from the perspective of a clean and logical programming >> model, perhaps not so much. Assignment is imperative, not functional, and >> requiring it to return a result is somewhat unclean. > > I thought practicallity beats purity? AFAICS python doesn't use such a > clean and logical programming model and it isn't given much critique over > it. So I don't think it is fair to critique assignment as an expression > because of this aspect.
Python is a remarkably clean and consistent language. There's only one kind of value (the object -- everything is an object, even classes are objects). The syntax isn't full of special cases. For example, there's nothing like this horror from Ruby: #!/usr/bin/ruby def a(x=4) x+2 end b = 1 print "a + b => ", (a + b), "\n" print "a+b => ", (a+b), "\n" print "a+ b => ", (a+ b), "\n" print "a +b => ", (a +b), "\n" which prints: 7 7 7 3 This is not a bug in the language (well, yes it is, it's a design bug), but it is a consequence of the syntax. Python has nothing like this. Python's syntax is quite clean and consistent. [...] > But we are not talking about all commands, we are just talking about > assignments. Sure an assignment has a side effect. But so has ls.pop(). So > something having a side-effect and a value is not unheard of even within a > python context. Sure, I already said that some commands might return a value. But assignment? Assignment is a pure command. There's nothing to return. Having `x = 23` return 23 is, well, weird. If we start from the premise that a return result is generated from a *calculation* or a *query*, we have to ask what is being calculated or asked? I'm not quite willing to say that assignment-as-expression is an error, because I acknowledge that it could be useful in some places. But it seems bolted on and arbitrary, like having del return the name you just unbound: assert (del x) == 'x' And one other reason why I dislike it: it makes for a verbose and messy interactive experience. Take Ruby: irb(main):001:0> a = 23 => 23 I don't need to see 23 printed, because I already know what the value is, so that takes two lines where one would do. (On the rare case I did want to see the value of something I had just assigned to, I could just print the expression.) -- Steven -- https://mail.python.org/mailman/listinfo/python-list