On Oct 28, 5:49 am, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote:
> It's sure as hell more beautiful and readable than assignment as an > expression. > > If we are going to judge code on the ability of people to take a quick > glance and immediately understand it, then pretty much nothing but > trivial one-liners will pass. Certainly assignment as an expression won't: > > while (look_ahead(it) and next(it) or default).strip().lower() as line: > spam(x) > > is easy to miss that it is an assignment to x. *Much* easier than missing > an indented "break". > > > In > > my opinion I shouldn't be obliged to read any of the indented lines of > > the while statement on a first 'visual' pass through somebody elses code > > and still be able to see what the loop iterates through. > > Fine. Then write your code as: > > line = function(x, y, z) > while line: > do something with(line) > line = function(x, y, z) > > > Following looks in my opinion nicer. > > > while complex_expression as line: > > do_something_with(line) > > That's only because you don't actually have a complex expression. Just > writing "complex_expression" doesn't make it complex -- it's actually > trivially simple, a mere rebinding of a name to a name, no more "complex" > than > > while x as y: > ... > > See how easy to read it is! Well duh. But write out an *actual* complex > expression, and the "as name" can easily disappear into the noise. > > Complex expressions are a code smell at least as bad as violating DRY, > and frequently much worse. If the expression is too complex to write > twice, refactor it into a function, *and write tests for the function*. > Otherwise that complex expression is a bug waiting to bite, whether you > write it once or twice. The details of the various syntaxes proposed Ive not fully gone into and I am not discussing. The general notion of having assignments inside expressions would put python into the C bracket I had written about the 'all-hell-breaks-loose' when using C to teach programming: http://www.the-magus.in/Publications/chor.pdf That paper is dated... if C is dated. Otherwise I would request people having this idea to read it. In particular, with respect to this suggestion, heres how things tend to pan out when the language allows assignments inside expressions: You cant really *teach* students to use i=i+1; instead of i++; because its unidiomatic C. And then someone (with no malice just ignorance) writes: i=i++; What does the teacher do? You can simply say: "Dont do that!!" and confuse the students with what exactly is the set of "Dont-dos" (or worse leave them smug that they understand when they dont) Or you can explain why it could increment i or leave it unchanged and so is indeterminate. So I would take the 'muscular' approach -- Show expressions like: i=i++-1; 1. Explain why it could increment, decrement or leave i unchanged 2. Elaborate compilation strategies for each of the above 3. Work out sufficient conditions for the behavior of an expression to be determinate, viz. Variables that are assigned inside an expression, should have only a single occurence, multiply occurring variables should not be assigned. [And assignment means all forms: = += ++ etc) Naturally when students are taught like this, they tend to become cowboys -- learning all kinds of tricks of a narrow and useless sort and ignoring more important aspects of their studies. And if python chooses such a direction its sad (for us teachers) Having said this I need to add: the imperatives of teaching and professional development are not the same. If professional developers feel that adding confusing semantics for the sake of saving lines of code is a benediction... Well... -- http://mail.python.org/mailman/listinfo/python-list