On Fri, 7 Sep 2018 at 15:10, Paul Moore <p.f.mo...@gmail.com> wrote: > > On Fri, 7 Sep 2018 at 14:06, Steven D'Aprano > <steve+comp.lang.pyt...@pearwood.info> wrote: > > > > On Thu, 06 Sep 2018 13:48:54 +0300, Marko Rauhamaa wrote: > > > > > Chris Angelico <ros...@gmail.com>: > > >> The request was to translate this into Python, not to slavishly imitate > > >> every possible semantic difference even if it won't actually affect > > >> behaviour. > > > > > > I trust Steven to be able to refactor the code into something more > > > likable. His only tripping point was the meaning of the "let" construct. > > > > Thanks for the vote of confidence :-) > > > > However I have a follow up question. Why the "let" construct in the first > > place? Is this just a matter of principle, "put everything in its own > > scope as a matter of precautionary code hygiene"? Because I can't see any > > advantage to the inner function: > > My impression is that this is just functional programming "good > style". As you say, it's not needed, it's just "keep things valid in > the smallest range possible". Probably also related to the > mathematical style of naming sub-expressions. Also, it's probably the > case that in a (compiled) functional language like SML, the compiler > can optimise this to avoid any actual inner function, leaving it as > nothing more than a temporary name.
It's also worth noting that functional languages don't typically have variables or assignments (more accurately, such things aren't fundamental to the programming model the way they are in imperative languages). So although technically let introduces a new scope, in practical terms it's basically just "how functional programmers do assignments". Paul -- https://mail.python.org/mailman/listinfo/python-list
