On 23 February 2017 at 13:37, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:

Note that this has been suggested before at least once (https://mail.python.org/pipermail/python-dev/2007-November/075257.html), and that thread itself suggests it has been suggested before and shutdown by Guido (though no source is given for this).

Thanks for your interest, but as you note this has already been proposed and rejected (from my personal recollection, more than once). So the key question is surely, what are you proposing that wasn't already discussed in previous threads, and why do you think that the new aspect of your proposal is likely to change Guido's mind? Sorry to be blunt, but rehashing an already extensively discussed idea isn't that productive for anyone. Paul

Hi Paul, Daniel, others, That is fair enough and the right amount of blunt. Let me go through the points that were made in that thread (I have not found any other threads, if someone links to them, I will go through them as well): ----- From: https://mail.python.org/pipermail/python-dev/2007-November/075258.html, alternative solution (in current language):

for x in (x for x in range if is_prime(x)): # do something with x

This statement seems overly complicated for what it is trying to achieve and is semantically much harder to parse than the proposed alternative, e.g. there is repetition of the string "for x in". ---- A similar point to where I started from in https://mail.python.org/piperm ail/python-ideas/2016-September/042600.html:

"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"

---- The thread Daniel mentioned was ended by the following post https://mail.python.org/pipermail/python-ideas/2016-September/042285.html

Generally speaking, we only add new syntax in cases where we're 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."

I am not sure I agree with what he is saying (or I am not following it...). I think no-one in that thread particularly demonstrated why this could not supersede all equivalent solutions, even if the if is longer (but not complex), one can simply do: for x in range(10) \ if is_prime(x) and is_overabundant(x) and is_perfect(x) and x != 5: # do something with x where you would line up the if with the range/... on the previous line (this example is silly, because the conditions cannot be satisfied). This in my view would still be clearer and more concise than the alternative solutions. The emails in the threads seem to indicate that almost everyone is a shade of grey here, where some really like it (but can life without), some think it is alright but don't particularly mind, and some think it is not the worth the cost or would allow abuse. No-one seems to fundamentally hate the idea, or in a alternative world where it was already in Python, would suggest taking it out (even if it a backwards-incompatible epoch like 2->3 was approaching) though my reading between the lines of emails can be wrong. I think Erik's email (see above) shows this most clearly. In a straw poll at the company I work at everyone was in favour, though they obviously are not in charge of implementing or changing documentation so that is easy for them to say, they've got no skin in the game. I don't know whether it is common for such an idea to be brought up again and again by newcomers/those who don't strolls the archives enough, but if it keeps being brought up, and the main argument against is it would take time and effort to document and implement for little benefit, if Python sticks around for a long enough time, it will end up taking less time simply implement it! Best, Henk-Jaap On 23 February 2017 at 13:54, Daniel Moisset <dmoisset@machinalis.com> wrote:

Just as a reference, I think the most recent reincarnation of this thread was: https://mail.python.org/pipermail/python-ideas/2016-Sep tember/042270.html

On 23 February 2017 at 13:46, Paul Moore <p.f.moore@gmail.com> wrote:

...

On 23 February 2017 at 13:37, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:

...

Note that this has been suggested before at least once (https://mail.python.org/pipermail/python-dev/2007-November/075257.html ), and that thread itself suggests it has been suggested before and shutdown by Guido (though no source is given for this).

Thanks for your interest, but as you note this has already been proposed and rejected (from my personal recollection, more than once).

So the key question is surely, what are you proposing that wasn't already discussed in previous threads, and why do you think that the new aspect of your proposal is likely to change Guido's mind?

Sorry to be blunt, but rehashing an already extensively discussed idea isn't that productive for anyone.

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

-- Daniel F. Moisset - UK Country Manager www.machinalis.com Skype: @dmoisset

On 23 February 2017 at 13:54, Daniel Moisset <dmoisset@machinalis.com> wrote:

Just as a reference, I think the most recent reincarnation of this thread was: https://mail.python.org/pipermail/python-ideas/2016-Sep tember/042270.html

On 23 February 2017 at 13:46, Paul Moore <p.f.moore@gmail.com> wrote:

...

On 23 February 2017 at 13:37, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:

...

Note that this has been suggested before at least once (https://mail.python.org/pipermail/python-dev/2007-November/075257.html ), and that thread itself suggests it has been suggested before and shutdown by Guido (though no source is given for this).

Thanks for your interest, but as you note this has already been proposed and rejected (from my personal recollection, more than once).

So the key question is surely, what are you proposing that wasn't already discussed in previous threads, and why do you think that the new aspect of your proposal is likely to change Guido's mind?

Sorry to be blunt, but rehashing an already extensively discussed idea isn't that productive for anyone.

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

-- Daniel F. Moisset - UK Country Manager www.machinalis.com Skype: @dmoisset

On 23 February 2017 at 14:20, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:

In a straw poll at the company I work at everyone was in favour, though they obviously are not in charge of implementing or changing documentation so that is easy for them to say, they've got no skin in the game. I don't know whether it is common for such an idea to be brought up again and again by newcomers/those who don't strolls the archives enough, but if it keeps being brought up, and the main argument against is it would take time and effort to document and implement for little benefit, if Python sticks around for a long enough time, it will end up taking less time simply implement it!

We really need a FAQ for this, if there isn't one already. You quoted Nick referring to a post I'd already made on this, and while I'm afraid I don't have time to find a link for you, I'll try to summarise again here. The bar for syntax changes to Python (and also library changes, although to a slightly lesser extent) is deliberately very high. This is not because people don't like proposals, but rather because the proposers consistently and drastically underestimate the cost of adding new features to the language. Things that need to be factored into the cost of a change: 1. Written materials, such as books, training courses, blog posts will be out of date, at best offering obsolete advice, at worst being outright wrong. Either the authors have extra work to do to change them, or the readers need to learn the "new truth", probably by making mistakes that they could have avoided if the material were correct. 2. Core developers need to understand the implementation of the new feature in order to support it. 3. Unintended consequences and/or problems with the design of the new feature (= bugs) need to be fixed. 4. People writing code that needs to support multiple versions of Python probably won't benefit, as they'll have to avoid the feature. But they will pay costs: a) They need to review that decision over time - is the new feature compelling enough that we should drop support for older versions yet? b) If there's an existing way of writing the construct, why ever change to the new version at all? c) PRs written by people used to the new feature will need reviewing and fixing for compatibility. 5. People not interested in the new feature will encounter it in other people's code and will need to understand it. 6. Someone has to code it. It's often not at all clear whether the proposer is offering to spend the time implementing the feature, and we typically don't bluntly say "well, will you write the code?" both because it's a bit aggressive, and also because an answer of "yes" isn't enough by itself - so we don't want to mislead people that the *only* problem is finding someone to code the change. There's probably others that I have missed. In addition, there's a couple of other points, not directly related to cost but still downsides of new features: 1. People need to be able to search for the new feature and learn it. For syntax in particular, that's hard, as you can't search for something unless you know the right terms. Often a library function is better than syntax for precisely this reason. 2. If a new syntax is defined as "equivalent to XXX which is how you write it now", then (a) it immediately violates the "there should be one obvious way to do it" rule, *unless* the new syntax is so compelling as to immediately be seen as the new "obvious" way to do things. And (b) the people having to support older versions of Python (i.e. a *lot* of people) have no incentive to use the new construct because then they'd have to drop support for existing Python versions. Now, none of the above are insurmountable. We do get new syntax features - and they aren't always massive like async or typing. Unpacking generalisations and f-strings are recent new syntax. But you have to have a *really* good story in terms of benefits to pass the bar. And that means a lot more than just "most people on the list weren't actively against it" in the case of a proposal that's already been made and rejected. Regarding your other points, it *is* hard for newcomers to know what's an old idea. We do what we can (even to the extent of sometimes recommending PEPs just so that ideas can be formally rejected for reference) but not everyone reads up on the history, and we try to be forgiving of that. Your original post showed that you had done some research, so thanks for that. Hopefully, we can work on clarifying for people like you why the "it keeps coming up" argument isn't sufficient by itself. As regards "it will take less time in the end to implement it", if only that were true :-) Sadly, most of the people contributing to discussions here (and even though I'm a core dev, I include myself here) don't actually write code for the Python core that often - whether because time to write emails is easier to find than time to code, or for other reasons, isn't that important. So even we were all to spend a week off from Python-ideas, that wouldn't necessarily translate into new patches for Python. I hope that puts the discussion into context. Paul

Hi Paul, Thanks for typing that all out and taking the time to respond to my emails. I think as you say, it might be good to put this somewhere obvious. I did find https://docs.python.org/devguide/langchanges.html and http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-ch... but the things you wrote would be useful to add the former (or be linked from there). It would also be good if there was a counter-point to that blog post of changes (like this one) that are not sufficiently thought through or significant enough to be accepted: it is always good to have examples on both sides. In terms of your "it keeps coming up", maybe there should be a general PEP (or something else) that simply outlines a bunch of ideas (and will be kept adding to) that keep cropping up but have been rejected/received unsympathetically many times? Including maybe links to these threads? Maybe that is something that could save you (and others subscribed) time and effort? H-J On 23 February 2017 at 15:02, Paul Moore <p.f.moore@gmail.com> wrote:

On 23 February 2017 at 14:20, Henk-Jaap Wagenaar <wagenaarhenkjaap@gmail.com> wrote:

...

In a straw poll at the company I work at everyone was in favour, though

they

...

obviously are not in charge of implementing or changing documentation so that is easy for them to say, they've got no skin in the game. I don't know whether it is common for such an idea to be brought up again and again by newcomers/those who don't strolls the archives enough, but if it keeps being brought up, and the main argument against is it would take time and effort to document and implement for little benefit, if Python sticks around for a long enough time, it will end up taking less time simply implement it!

We really need a FAQ for this, if there isn't one already. You quoted Nick referring to a post I'd already made on this, and while I'm afraid I don't have time to find a link for you, I'll try to summarise again here.

The bar for syntax changes to Python (and also library changes, although to a slightly lesser extent) is deliberately very high. This is not because people don't like proposals, but rather because the proposers consistently and drastically underestimate the cost of adding new features to the language.

Things that need to be factored into the cost of a change:

1. Written materials, such as books, training courses, blog posts will be out of date, at best offering obsolete advice, at worst being outright wrong. Either the authors have extra work to do to change them, or the readers need to learn the "new truth", probably by making mistakes that they could have avoided if the material were correct. 2. Core developers need to understand the implementation of the new feature in order to support it. 3. Unintended consequences and/or problems with the design of the new feature (= bugs) need to be fixed. 4. People writing code that needs to support multiple versions of Python probably won't benefit, as they'll have to avoid the feature. But they will pay costs: a) They need to review that decision over time - is the new feature compelling enough that we should drop support for older versions yet? b) If there's an existing way of writing the construct, why ever change to the new version at all? c) PRs written by people used to the new feature will need reviewing and fixing for compatibility. 5. People not interested in the new feature will encounter it in other people's code and will need to understand it. 6. Someone has to code it. It's often not at all clear whether the proposer is offering to spend the time implementing the feature, and we typically don't bluntly say "well, will you write the code?" both because it's a bit aggressive, and also because an answer of "yes" isn't enough by itself - so we don't want to mislead people that the *only* problem is finding someone to code the change.

There's probably others that I have missed.

In addition, there's a couple of other points, not directly related to cost but still downsides of new features:

1. People need to be able to search for the new feature and learn it. For syntax in particular, that's hard, as you can't search for something unless you know the right terms. Often a library function is better than syntax for precisely this reason. 2. If a new syntax is defined as "equivalent to XXX which is how you write it now", then (a) it immediately violates the "there should be one obvious way to do it" rule, *unless* the new syntax is so compelling as to immediately be seen as the new "obvious" way to do things. And (b) the people having to support older versions of Python (i.e. a *lot* of people) have no incentive to use the new construct because then they'd have to drop support for existing Python versions.

Now, none of the above are insurmountable. We do get new syntax features - and they aren't always massive like async or typing. Unpacking generalisations and f-strings are recent new syntax. But you have to have a *really* good story in terms of benefits to pass the bar. And that means a lot more than just "most people on the list weren't actively against it" in the case of a proposal that's already been made and rejected.

Regarding your other points, it *is* hard for newcomers to know what's an old idea. We do what we can (even to the extent of sometimes recommending PEPs just so that ideas can be formally rejected for reference) but not everyone reads up on the history, and we try to be forgiving of that. Your original post showed that you had done some research, so thanks for that. Hopefully, we can work on clarifying for people like you why the "it keeps coming up" argument isn't sufficient by itself.

As regards "it will take less time in the end to implement it", if only that were true :-) Sadly, most of the people contributing to discussions here (and even though I'm a core dev, I include myself here) don't actually write code for the Python core that often - whether because time to write emails is easier to find than time to code, or for other reasons, isn't that important. So even we were all to spend a week off from Python-ideas, that wouldn't necessarily translate into new patches for Python.

I hope that puts the discussion into context.

Paul

Hi Henk-Jaap, thanks for your "if in for" proposal. Paul's comments are all "motherhood statements" against a generic proposal. It's nothing that would prevent your specific proposal from being accepted or not. And there's no rejected PEP for this feature as far as I can see. Skimming through the other thread about this topic, I remember me not being very offensive against it. I would use it often. IIRC, one result of former discussions were that it would be technically possible. But the other proposer did not convince most thread participants back then. I for one, though, didn't buy the counter-arguments and still don't. They still sound to me like abstract fears. On 23.02.2017 16:18, Henk-Jaap Wagenaar wrote:

I did find https://docs.python.org/devguide/langchanges.html and http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-ch... but the things you wrote would be useful to add the former (or be linked from there). It would also be good if there was a counter-point to that blog post of changes (like this one) that are not sufficiently thought through or significant enough to be accepted: it is always good to have examples on both sides.

In terms of your "it keeps coming up", maybe there should be a general PEP (or something else) that simply outlines a bunch of ideas (and will be kept adding to) that keep cropping up but have been rejected/received unsympathetically many times? Including maybe links to these threads?

Recently, we had a similar discussion about writing an "official" document which might prevent proposal such as yours. I wasn't the only one being offended by this kind of thinking. There are, as you noted, two sides of the table and just because "it keeps coming up" and "was received unsympathetically many times" doesn't mean we shouldn't consider it. Point is, it actually seems sympathetic to many people and this is why it keeps coming up. Nevertheless, a proposal needs consensus. Regards, Sven

On Thu, Feb 23, 2017 at 03:33:32PM +0000, Paul Moore wrote:

Ha. I never even *thought* of putting something like this in the devguide. Thanks for the pointer. I'll try to make some time to polish up my comments and put a PR together for that.

Paul, at the moment I have neither the time nor the mental energy to deal with learning the brave New World of Github's way of doing things, but if you want to adapt my "Things That Won't Change" proto-PEP from last month, please feel free to do so! I have an update to the original version, over the next couple of days, time permitting, I'll clean it up and send it to the list.

I've thought we should have some sort of "list info" page describing things like this and giving some context for posters before now. Possibly linked from the automatic footer the list adds. I don't know who would be able to do something like that, though.

The obvious places to link to this page are: - the Python-Ideas signup page; - the devguide; - the FAQs. -- Steve

Hey Steven, On 23.02.2017 19:25, Steven D'Aprano wrote:

Indeed not. The Pythonic solution is exactly the one you used: DON'T combine the for-loop and if-statement.

for x in range(100): if is_prime(x): ...

If the use of two lines and two indents is truly a problem, to the point that you really need to refactor to a single line, that's a code smell: your function is probably too big, too complex and does too much, and should be refactored.

May I disagree with you here? I write many functions with a single for loop + a single if+continue on a daily basis (usually generators). They don't seem to look like code-smell to me. Not saying they justify this feature but it's easier to read a positive (including) if than a negative one (skipping).

Deeply nested for...for...for...if...if...if...for... blocks look ugly because they are ugly. Allowing them all on one line makes the Python language worse, not better. It is unfortunate that comprehensions, by their nature, must allow that sort of thing, but that doesn't mean we have to allow it elsewhere.

Another disagreement here. Just because it's possible to do ugly stuff with a hammer shouldn't mean we cannot allow hammers. It's an argument neither in favor of nor against the proposal. Sven

On Fri, Feb 24, 2017 at 3:28 PM, Steven D'Aprano <steve@pearwood.info> wrote:

There is nothing wrong with a nested for...if pair of statements. But that does take two lines, and two indents, rather than one:

block for ... if ... block

versus hypothetical:

block for ... if ... block

The proposed syntax saves one line, and one indent. That is a saving, but it is not a big saving. If one line and one indent *really* makes a difference to a piece of code, it is probably because you are already deeply nested:

class ... def ... def ... try ... try ... while ... try ... if ... with ... if ... while ... for ... if ... # not enough # room here

Don't forget that you can rewrite a "for-if" using two additional lines and no indents, rather than one line and one indent: for ...: if not (...): continue ... ... So you can take your pick which version you want. Granted, I can still see value in the for-if statement, but not enough to justify new syntax. ChrisA