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. > Look at it this way: suppose you had a robot servant that always, without > fail or misunderstanding, did what you instructed. There are broadly two > sorts of things that you can give as instructions: questions, and commands. > Questions always require an answer: "What's the length of this list?" is > functional. Commands are imperative, not functional, and don't necessarily > require an answer: "Move the small red pyramid onto the large green cube." > Some commands arguable might require an answer, but arguable they are > better served by an out-of-band error condition (an exception). *Requiring* > all commands to give an answer is silly, given that the robot servant is > infallible. 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. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
