On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:

On 09/11/2016 06:36 AM, Dominik Gresch wrote:

...

So I asked myself if a syntax as follows would be possible:

for i in range(10) if i != 5: body

Personally, I find this extremely intuitive since this kind of if-statement is already present in list comprehensions.

What is your opinion on this? Sorry if this has been discussed before -- I didn't find anything in the archives.

I find it interesting.

I thing that this will likely take up too many columns in more convoluted loops such as

for element in collection if is_pretty_enough(element) and ...: ...

However, this "problem" is already faced by list comprehensions, so it is not a strong argument against your idea.

Sorry to re-raise this thread--I'm inclined to agree that the case doesn't really warrant new syntax. I just wanted to add that I think the very fact that this syntax is supported by list comprehensions is an argument *in its favor*. I could easily see a Python newbie being confused that they can write "for x in y if z" inside a list comprehension, but not in a bare for-statement. Sure they'd learn quickly enough that the filtering syntax is unique to list comprehensions. But to anyone who doesn't know the historical progression of the Python language that would seem highly arbitrary and incongruous I would think. Just $0.02 USD from a pedagogical perspective. Erik

On Tue, Sep 27, 2016 at 5:33 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 28 September 2016 at 00:55, Erik Bray <erik.m.bray@gmail.com> wrote:

...

On Sun, Sep 11, 2016 at 12:28 PM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:

...

On 09/11/2016 06:36 AM, Dominik Gresch wrote:

...

So I asked myself if a syntax as follows would be possible:

for i in range(10) if i != 5: body

Personally, I find this extremely intuitive since this kind of if-statement is already present in list comprehensions.

What is your opinion on this? Sorry if this has been discussed before -- I didn't find anything in the archives.

I find it interesting.

I thing that this will likely take up too many columns in more convoluted loops such as

for element in collection if is_pretty_enough(element) and ...: ...

However, this "problem" is already faced by list comprehensions, so it is not a strong argument against your idea.

Sorry to re-raise this thread--I'm inclined to agree that the case doesn't really warrant new syntax. I just wanted to add that I think the very fact that this syntax is supported by list comprehensions is an argument *in its favor*.

I could easily see a Python newbie being confused that they can write "for x in y if z" inside a list comprehension, but not in a bare for-statement. Sure they'd learn quickly enough that the filtering syntax is unique to list comprehensions. But to anyone who doesn't know the historical progression of the Python language that would seem highly arbitrary and incongruous I would think.

Just $0.02 USD from a pedagogical perspective.

This has come up before, and it's considered a teaching moment regarding how the comprehension syntax actually works: it's an *arbitrarily deep* nested chain of if statements and for statements.

That is:

[f(x,y,z) for x in seq1 if p1(x) for y in seq2 if p2(y) for z in seq3 if p3(z)]

can be translated mechanically to the equivalent nested statements (with the only difference being that the loop variable leak due to the missing implicit scope):

result = [] for x in seq1: if p1(x): for y in seq2: if p2(y): for z in seq3: if p3(z): result.append(f(x, y, z))

So while the *most common* cases are a single for loop (map equivalent), or a single for loop and a single if statement (filter equivalent), they're not only the forms folks may encounter in the wild.

Thanks for pointing this out Nick. Then following my own logic it would be desirable to also allow the nested for loop syntax of list comprehensions outside them as well. That's a slippery slope to incomprehensibility (they're bad enough in list comprehensions, though occasionally useful). This is a helpful way to think about list comprehensions though--I'll remember it next time I teach them. Thanks, Erik

Erik Bray wrote:

Then following my own logic it would be desirable to also allow the nested for loop syntax of list comprehensions outside them as well.

The only use for such a syntax would be to put an inadvisable amount of stuff on one line. When describing a procedural series of steps, the Pythonic style encourages putting each step on its own line. Other areas of the language also nudge one in this direction, e.g. the fact that mutating operations usually return None, which discourages chaining them together into a single expression. -- Greg

for x in seq1 if p1(x)\ for y in seq2 if p2(y)\ for z in seq3 if p3(z): result.append(f(x, y, z))

It think it is not uncommon to have nested loops, maybe with an if/continue statement at the beginning, with only one logical block that then should go down only one indentation level rather than three or four. An alternate way may be from itertools import product for x,y,z in filter(lambda x:p1(x[0]) and p2(x[1]) and p3(x[2]), \ product(seq1, seq3, seq3)): do_stuff(x,y,z) Doable, but seems kind of clunky. As a note, in general p2 could depend on x and y and p3 and x,y, and z; seq2 could depend on x and seq3 and x and y. The latter is something my example could not cover easily but only when explicitly writing out the loop, either in comprehension-style or "classic" loops. I think wasting of indentation levels for a single logical block should be avoided if possible to make the code more legible, otherwise one hits the suggested line length limit too fast - suppose this is now inside a method, you already lose at least 8 char ...

...

I think wasting of indentation levels for a single logical block should be avoided if possible to make the code more legible, otherwise one hits the suggested line length limit too fast - suppose this is now inside a method, you already lose at least 8 char ...

Hence generators, which allow the nested loops to be readily factored out into a named operation.

def iter_interesting_triples(seq1, seq2, seq3): for x in seq1: if p1(x): for y in seq2: if p2(x, y): for z in seq3: if p3(x, y, z): yield x, y, z

for x, y, z in iter_interesting_triples(seq1, seq2, seq3): f(x, y, z)

This is an elegant solution, but I think it makes the code less clear if one has to loop up the definition of the generator. I any case, irrespective of limits or being dispensable, I think it would be more consistent for the language to allow the same syntax for "for" loops as is allowed in comprehensions.

On Sun, Sep 11, 2016 at 9:59 PM, Paul Moore <p.f.moore@gmail.com> wrote:

# Hacky use of a generator expression: for i in (x for x in range(10) if x != 5): body()

This is what I'd like to compare the proposal against. It's perfectly legal but pretty ugly - why should you nest two 'for' loops just for the sake of filtering?

# Functional style for i in filter(range(10), lambda n: n != 5): body()

And this one is very close (I'd use i instead of n in the lambda function), but still fairly verbose. That said, though, filtered iteration isn't common enough to demand its own syntax IMO. I do it fairly often, but it's usually fine to just have a condition on a separate line. (I do use ": continue" rather than making it two lines.) ChrisA

On 11.09.2016 22:15, C Anthony Risinger wrote:

On Sep 11, 2016 7:11 AM, "Chris Angelico" <rosuav@gmail.com <mailto:rosuav@gmail.com>> wrote:

...

That said, though, filtered iteration isn't common enough to demand its own syntax IMO. I do it fairly often,

I do it often enough to want this.

Same here. Most of the time it's just a single condition which disturbs the coherence of the loop body.

When I first started writing Python this struck me as an inconsistency... if it's useful in comprehensions, why not regular loops? I realize comprehensions are all about construction of the list itself, but the parallel still exists.

Also feels similar to guard statements. I'd love to see Python gain more pattern matching and destructuring features because they are wonderful in Erlang/Elixir.

...

but it's usually fine to just have a condition on a separate line. (I do use ": continue" rather than making it two lines.)

FWIW, code I write or review would mandate this be two lines followed by a blank line, so 3 total. I require any abrupt change or termination in the current flow of control to be followed by a blank line so the reader clearly sees the possible jump (continue, break, and return especially).

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Ok, I guess it's time to end this thread. Thank you all for your answers and the constructive discussion. Best, Dominik On 12.09.2016 08:25, Nick Coghlan wrote:

...

Hi,

I've recently found myself writing code similar to this:

for i in range(10): if i == 5: continue "body"

which I find a bit ugly. Obviously the same could be written as

for i in range(10): if i != 5: "body"

but here you would have to look at the end of the body to see if something happens when i==5. So I asked myself if a syntax as follows would be possible:

for i in range(10) if i != 5: body

Personally, I find this extremely intuitive since this kind of if-statement is already present in list comprehensions.

What is your opinion on this? Sorry if this has been discussed before -- I didn't find anything in the archives. Generally speaking, we only add new syntax in cases where we're

On 11 September 2016 at 19:36, Dominik Gresch <greschd@gmx.ch> wrote: prepared to say "In all cases where the new syntax applies, it should be used in preference to existing alternative spellings".

Special casing a single "if-continue" in a loop body doesn't meet that (deliberately high) bar, with Paul Moore's email going into some more detail on the specifics of that.

Cheers, Nick.

On 4 October 2016 at 08:18, Erik <python@lucidity.plus.com> wrote:

The expression suggested could be spelled:

for i in range(10): if i != 5: body

So, if a colon followed by another suite is equivalent to the same construct but without the INDENT (and then the corresponding DEDENT unwinds up to the point of the first keyword) then we get something that's pretty much as succinct as Dominik suggested.

What's the pay-off though? The ultimate problem with deeply nested code isn't the amount of vertical whitespace it takes up - it's the amount of working memory it requires in the brain of a human trying to read it. "This requires a lot of lines and a lot of indentation" is just an affordance at time of writing that reminds the code author of the future readability problem they're creating for themselves. Extracting named chunks solves the underlying readability problem by reducing the working memory demand in reading the code (assuming the chunks are well named, so the reader can either make a useful guess about the purpose of the extracted piece without even looking at its documentation, or at least remember what it does after looking it up the first time they encounter it). By contrast, eliminating the vertical whitespace without actually reducing the level of nesting is merely hiding the readability problem without actually addressing it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

These are my opinions; I don't claim any authority for them. I just don't find the proposed syntax as obvious and unambiguous as you do, and would like to explain why that is so. Ken Kundert writes:

In my experience it is exceptions and inconsistencies that consume 'working memory in the brain of humans'. By eliminating the distinction between list comprehensions and for loops we would be making the language simpler by eliminating an inconsistency.

I don't think of a comprehension as a for loop, I think of it as setbuilder notation (although of course I realize that since lists are sequences it has to be a for loop under the hood). So the claimed inconsistency here doesn't bother me. I realize it bothers a lot of people, but the proposed syntax is not obvious to me (ambiguous and inconsistent in its own way).

[T]he writing of the generator function represents a speed bump.

It used to be, for me, but it really isn't any more. Perhaps you might get used to it if you tried it. Harder to argue: the fact that Guido and Nick (inter alia) consider it good style to use named functions makes that point a hard sell (ie, you don't need to convince me, you need to convince them).

Whereas writing something like the following is simple, compact, quick, and obvious. There is no reason why it should not be allowed even though it might not always be the best approach to use:

for i in range(5) for j in range(5) for k in range(5): ...

To me, that is visually ambiguous with for i in (range(5) for j in (range(5) for k in range(5))): ... although syntactically the genexp requires the parentheses (and in fact is almost nonsensical!) I could easily see myself forgetting the parentheses (something I do frequently) when I *do* want to use a genexp (something I do frequently), with more or less hilarious results. As already mentioned: for i, j, k in itertools.product(range(5), range(5), range(5)): ... To me that is much clearer, because it expresses the rectangular shape of the i, j, k space. I would also stumble on for i in range(5) for j in range(i + 1): ... at least the first few times I saw it. Based on the English syntax of "for" (not to mention the genexp syntax), I would expect for j in range(i + 1) for i in range(5): ... If itertools.product is the wrong tool, then the loop bodies are presumably complex enough to deserve new indent levels. Note that simple filters like non_nil (see below) can easily be used, as long as the resulting set is still a product.

And I would really like to be able to write loops of the form:

for item in items if item is not None: ...

def non_nil(items): return (item for item in items if item is not None) for item in non_nil(items): ... I think that's very readable, so the only reason why that 2-line function needs to be syntax that I can see is your distaste for defining functions, and that of other Python programmers who think like you.

In my mind, these proposed complications of the 'for' loop would *introduce* inconsistency, NOT reduce it. It's simple to remember that suites nest statements while comprehensions are expressions on single (logical) lines. Adding more edge cases to blue the distinction makes cognitive load higher. On Oct 3, 2016 9:38 PM, "Ken Kundert" <python-ideas@shalmirane.com> wrote:

In my experience it is exceptions and inconsistencies that consume 'working memory in the brain of humans'. By eliminating the distinction between list comprehensions and for loops we would be making the language simpler by eliminating an inconsistency.

Furthermore, I do not believe it is valid to discard a potentially good idea simply because if taken to extreme it might result in ugly code. With that justification one could reject most ideas. The fact is, that in many cases this idea would result in cleaner, more compact code. We should be content to offer a language in which it is possible to express complex ideas cleanly and simply, and trust our users to use the language appropriately.

For example, it was suggested that one could simplify a multi-level loop by moving the multiple levels of for loop into a separate function that acts as generator. And that is a nice idea, but when writing it, the writing of the generator function represents a speed bump. Whereas writing something like the following is simple, compact, quick, and obvious. There is no reason why it should not be allowed even though it might not always be the best approach to use:

for i in range(5) for j in range(5) for k in range(5): ...

And I would really like to be able to write loops of the form:

for item in items if item is not None: ...

It is something I do all the time, and it would be nice if it did not consume two levels on indentation.

-Ken

On Tue, Oct 04, 2016 at 01:31:22PM +1000, Nick Coghlan wrote:

...

On 4 October 2016 at 08:18, Erik <python@lucidity.plus.com> wrote:

...

The expression suggested could be spelled:

for i in range(10): if i != 5: body

So, if a colon followed by another suite is equivalent to the same construct but without the INDENT (and then the corresponding DEDENT unwinds up to the point of the first keyword) then we get something that's pretty much as succinct as Dominik suggested.

What's the pay-off though? The ultimate problem with deeply nested code isn't the amount of vertical whitespace it takes up - it's the amount of working memory it requires in the brain of a human trying to read it. "This requires a lot of lines and a lot of indentation" is just an affordance at time of writing that reminds the code author of the future readability problem they're creating for themselves.

Extracting named chunks solves the underlying readability problem by reducing the working memory demand in reading the code (assuming the chunks are well named, so the reader can either make a useful guess about the purpose of the extracted piece without even looking at its documentation, or at least remember what it does after looking it up the first time they encounter it).

By contrast, eliminating the vertical whitespace without actually reducing the level of nesting is merely hiding the readability problem without actually addressing it.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

---

Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:

Extra newlines are cheap. Writing

The cost is paid in newlines *and* extra levels of indentation. Why isn't it the programmer that is writing the code the best person to decide what is best? -Ken

Ken Kundert writes:

Why isn't it the programmer that is writing the code the best person to decide what is best?

Aside from what Paul said, there's a reason why this proposal is unlikely to attract support from senior devs. Python language design and style guides take the position that most code is read far more often than it is written. Unless there is an overriding advantage, recognized by the senior developers, Python will protect the reader by preferring syntax that keeps each control flow line simple in preference to saving the writer keystrokes, and even levels of indentation. Eg, there's no question in my mind that for i in range(m): for j in range (n): for k in range (p): m_out(i, k) += m_in1(i, j) * m_in2(j, k) is easier to read[1] than for i in range(m) for j in range (n) for k in range (p): m_out(i, k) += m_in1(i, j) * m_in2(j, k) despite costing two lines and two levels of indentation. YMMV, of course, but I suspect most senior devs will disagree with you. Footnotes: [1] It's also less painstaking to fix the bug.

On 5 October 2016 at 14:27, Sven R. Kunze <srkunze@mail.de> wrote:

For small scripts this is still useful. Not everybody writes huge programs, which needs to adhere to style guides and QA.

Sure. But convenience in small scripts and the REPL typically isn't a good enough argument to justify a language change. It's (to an extent) a point in favour of the proposal, but nobody's debating that. The problem is that we aren't seeing any *other* arguments in favour. And specifically not ones that provide benefits (or at least no disadvantages - "you don't need to use it" isn't enough, someone will be bound to try to and it'll have to be dealt with, hopefully in code review but maybe in maintenance) to large-scale production code, which is probably the vast majority of Python usage[1]. Let's take "it helps interactive use and quick scripts" as a given, and move on. Any other benefits? Readability has been demonstrated as subjective, so let's skip that. Paul [1] Although these days, data analysis / interactive exploration may be a growing proportion...

On 5 October 2016 at 17:26, Nick Coghlan <ncoghlan@gmail.com> wrote:

Compared to those, locally modifying the token stream to inject ": INDENT" pairs when the if and for keywords are encountered between an opening "for" keyword and a closing ":" keyword would be a relatively straightforward change that only impacted folks that decided they preferred that particular flavour of Abbreviated Python to the regular version.

It's also worth noting that the obvious response "but I don't want to have to run a preprocessor against my code" is another indication that this isn't solving a significant enough problem to warrant a language change. Again, this isn't a hard and fast rule, but it is a useful rule of thumb - how much effort are you willing to go to to get this feature without it being built in? That's one of the reasons "it should be made into a module on PyPI" is a useful counter to proposals for new stdlib functions. It's also worth looking at the cases where things get added despite not going via that route - sometimes "being built in" is an important benefit of itself. But typically that's because people are encouraged to use built in facilities, so guiding beginners (or not-so-beginners) into good practice is important. In this case, it's far from clear that the feature is actually good practice. Paul

On Tue, Oct 04, 2016 at 09:09:40PM -0700, Ken Kundert wrote:

On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:

...

Extra newlines are cheap. Writing

The cost is paid in newlines *and* extra levels of indentation.

You've quoted me out of context -- I did also refer to extra indentation being cheap. At the point that it isn't any more, it is a code smell and you (that's generic you, not just you personally) should think hard about how the design of your code.

Why isn't it the programmer that is writing the code the best person to decide what is best?

Have you *seen* the quality of code written by the average coder? And remember, fifty percent of coders are worse than that. I jest, but only a bit. For better or worse, of course every programmer can set their own style, within the constraints of the language. If they cannot bear the language contraints, they're free to use a different language, or design their own. Anyone can be "the best person to decide" for their own private language. All languages have their own style, of what is or isn't allowed, what's encouraged and what's discouraged, and their own idiomatic way of doing things. The syntax constraints of the language depend on the language designer, not the programmers who use it. For some languages, those constraints are set by those who are appointed to sit on a standards board, usually driven by the corporations with the deepest pockets. Python, it is Guido and the core developers who set the boundaries of what coding styles can work in Python, and while the community can influence that, it doesn't control it. It isn't a wild free-for-all where every programmer is "the best person to decide". Some people might think that moving closer towards a Perl-ish one-liner culture by allowing (say): for x in seq for y in items if cond: block makes Python better ("saves some lines! saves some indents!"), but to those who like the discipline and structure of Python's existing loop syntax, this will make Python significantly worse. No decision can please everybody. -- Steve