On Wed, Jul 21, 2010 at 9:21 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 7/21/2010 7:24 AM, Nick Coghlan wrote:
On Wed, Jul 21, 2010 at 9:16 PM, Stefan Behnel<stefan_ml@behnel.de> wrote:
Terry Reedy, 20.07.2010 21:49:
I did not comment then because I thought the idea of cluttering python with augmented local namespace blocks, with no functional gain, was rejected and dead, and hence unnecessary of comment. -10 For me, the idea would come close to destroying (what remains of) the simplicity that makes Python relatively easy to learn. It seems to be associated with the (to me, cracked) idea that names are pollution.
Actually, it's about *giving* names to subexpressions, that's quite the opposite.
I think Terry's point was that you can already give names to subexpressions by assigning them to variables in the current scope, but some people object to that approach due to "namespace pollution".
Right.
I agree with him that avoiding namespace pollution isn't a particular strong argument though (unless you have really long scripts and
Okay, we can leave that issue aside.
functions), which is why I've tried to emphasize the intended readability benefits.
whereas I am trying to emphasize the reading horror for people whose brains are wired differently from yours. The backwards conditional expressions are nearly impossible for me to read, which is to say, painful. To some, something like
Ok, so, your brain is wired differently. That's fine- but mine says that there are cases where the up-front syntax is more readable. I particularly like that it clearly marks what variables will not be used elsewhere without forcing me to jump around in the code to find out how they're being computed.
e = fe(a,b,c, p1) where: c = fc(a, d, p2 where: d = fd(a, p1) where: a = fa(p1, p2) b = fb(a,p2)
where p1,p2 are input parameters;
looks about as bad (and it was a real effort to write). I would rather something like that were in a branch dialect, Ypthon with its own extension (.yp).
Of course it looks bad. You can make anything look bad. 37 levels of nested 'for' statements look bad. That isn't an argument against this, it's an argument against bad code period.
Algorithm book authors usually want their books read by lots of people. When they invent a pseudocode language, they usually invent something lots of people can read. (Knuth's MIX was something of an exception.) It is often so close to (a subset of) Python that it is ridiculous that they do not just use (a subset) Python so it is not 'pseudo'. I cannot remember seeing anything like the above. I believe the reason is because it would be, on average, less readable and harder to understand.
I would use this, and would welcome it in a textbook. Telling people what you're doing before you do it motivates the material and helps people to learn and understand with minimal effort IMO/E. Geremy Condra