Reuse "for" to express "given"
I have read most of the PEP 572 related threads, but I don't think I've seen this idea. As many other people mentioned, Python already allows a trick to introduce local bindings in generator expressions and list comprehensions. This can be achieved by adding a "for var in [<expr>]" clause. I propose to make "for var = <expr>" have the same effect as "for var in [<expr>]". Note that in the case of filters, the order will be different from that in the original "given" proposal: instead of [(x, y, x/y) for x in data if y given y = f(x)] we will write [(x, y, x/y) for x in data for y = f(x) if y] The use of "for" in place of "given" in the if statements does not look too bad: if m for m = pattern.search(data): ... elif m for m = other_pattern.search(data)): ... else: ... I have to admit that while m for m = pattern.search(remaining_data): ... looks strange at first because both while and for are strongly associated with loops, but if you read "for var = <expr>" as "for var equals expression", the difference between that and "for var in (iterable) expression" becomes apparent.
This idea was mentioned (by me) at a time yes, but wasn't written in the document. I think one of the thing was that it would make the grammar non LL1 because when seeing the token "for" in a list comprehension it wouldn't know in advance if it's the loop or the assignment. And also, it might confuse people because 'for' is for iteration. Le jeu. 24 mai 2018 à 17:54, Alexander Belopolsky < alexander.belopolsky@gmail.com> a écrit :
On Thu, May 24, 2018 at 12:04 PM Robert Vanden Eynde <robertve92@gmail.com> wrote:
This idea was mentioned (by me) at a time yes, but wasn't written in the document.
Can you point me to a specific post? There were so may that I must have missed that one.
I don't see how that can be a problem. From the grammar point of view, "for" in "for var = <expr>" may still be seen as introducing a "loop", but when "=" is seen in place of "in", the compiler will resize that the "loop" is one a single value and emit efficient code for it. At the AST level, "for var = <expr>" will look exactly the same as "for var in <expr>" only with an "=" instead of "in".
And also, it might confuse people because 'for' is for iteration.
I think I addressed this in my previous post. Yes, for people with a C/C++ background, "for" may be too strongly associated with loops, but in mathematical sense, it seems clear that "for var in a set" means iteration over a set, while "for var = expression" means binding to a single value.
It was a long time ago I couldn't easily find the post but that's alright, you refreshed the idea :) Let's see what others think of for x = I also remembered some languages (like lua) use for x = range (5) interchangeably with for x in range (5) and guido said it will never make such a thing, for .. in being the iteration. Le jeu. 24 mai 2018 à 18:22, Alexander Belopolsky < alexander.belopolsky@gmail.com> a écrit :
I worry about the use of "for" because it will come up in contexts where "for" already has other meanings. In the case of the example list comprehension, the word "for" is being used to mean two entirely different things in a single expression, that seems rather precarious to me. I prefer "with" if we're looking for keywords to reuse. This feels fairly clean to me: [(x, y, x/y) for x in data with y = f(x) if y] if m with m = pattern.search(data): ... while m with m = pattern.search(remaining_data): ... Of course, "with" is not without problems and I'm not so happy about being able to: with open(a) as b with a = filename: ... --George On Thu, May 24, 2018 at 9:33 AM Robert Vanden Eynde <robertve92@gmail.com> wrote:
On Thu, May 24, 2018 at 11:54:09AM -0400, Alexander Belopolsky wrote:
C is well known for encouraging the "assignment instead of equals" error when people mistakenly use = when they mean ==. Instead of copying this design flaw, we'll have our own infamous design flaw: "assignment instead of looping" errors, when we mistakenly type "for var = thing" instead of "for var in thing" (or vice versa). Who says Python never innovates? :-) [...]
[(x, y, x/y) for x in data for y = f(x) if y]
[(x, y, x/y) for x in data if y := f(x)] In another post, you wrote: Yes, for people with a C/C++ background, "for" may be too strongly associated with loops, but in mathematical sense, it seems clear that "for var in a set" means iteration over a set, while "for var = expression" means binding to a single value. I don't come from a C/C++ background. I think "for" is strongly associated with loops in a large number of programming languages, including Python. http://rosettacode.org/wiki/Loops/For But I do have a mathematics background, and I don't remember ever seeing "for x = value" used in the sense you mean. I certainly wouldn't write that myself. I would expect to either: Given x = expression, then equation including x or the reverse order: equation including x where x = expression Normally I would only use "for" either in the context of sums, or the "for all" ∀ quantifier. (If that symbols doesn't show up, it is an upside down A.) -- Steve
But I do have a mathematics background, and I don't remember ever seeing "for x = value" used in the sense you mean.
That's so because in mathematics, "for" is spelled ":" as in {2*a* : *a*∈*Z*} If you can read the above, you should not have trouble reading {2*a* + *b* : *a*∈*Z *: *b = *1}
On Thu, May 24, 2018, 11:47 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Inverted "A" is "for all", and colon means "such that". It may be acceptable somewhere to use a colon as you do, but the lone colon unambiguously is "such that" when constructing sets. I never once saw colon used this way, and would be interested to see it in a proper math paper to correct my world view. "for" only reads as "such that" as: "A such that x = 1" "A, for x = 1" which sounds a bit Shakespearian and is definitely not common. standard math: "2a plus b for all integers such that b is 1." or "2a plus b for each integer such that b is 1" using "for" as ":": "2a plus b for a in integers for b in 1" or "2a plus b for a eauals integers for b eauals 1" or "2a plus b for all a in integers for all b in 1" Understandable, but I would get zero point on my homework for those, they are correct. In the context of math in general, ":=" makes more sense, and is actual math notation for assignment: http://mathworld.wolfram.com/Colon.html ignoring math: I'm kind of fine with nudging the meaning of "for" as you describe to be assignment, it's close enough, such that it's not a long leap. I think this point is the best case for "for", but I don't think being the only language to do this is great, and I usually don't care about language similarities. I lack breadth, however, so please correct me here. However, I cannot say this is superior to ":=" based on the same logic, as ":=" achieves the same ends with less semantic confusion, typing, and uses earlier indication of assignment. And please note that making "for" ambiguous when there is already the ambiguity in post fix notation makes the spelling less desirable to me. In this spelling, for one assignment, there are two ambiguities that must be resolved: the assigned name and the meaning of "for", though the latter is cleared up quickly. This small ambiguity is still there and I don't see a reason to introduce it. Thanks
On Thu, May 24, 2018 at 4:59 PM Matt Arcidy <marcidy@gmail.com> wrote:
See <https://en.wikipedia.org/wiki/Set_notation>. Also, "[list comprehensions] is Python's way of implementing a well-known notation for sets as used by mathematicians." < https://www.python-course.eu/list_comprehension.php>. Although, the latter uses "|" instead of ":".
On Thu, May 24, 2018, 14:48 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
My point was more along the lines of math doesn't use ":" for "for". "for" exists in math as a different symbol. Even in set builder notation ":" isn't interpretted as "for", it's "such that." Maybe the math discussion is totally tangential. I'm not clear why I'm making these points really, apologies if I took this off course, I'm happy to concede the math and just keep my other points. I don't think "for" is bad compared to some other alternatives, but I don't see it better than ":=" in the contexts you've raised. Even in the implementation of set building, "for" is only used to build the sets element wise, not as a partitioning, and is not a property if the set itself. Thanks,
On 24/05/2018 16:54, Alexander Belopolsky wrote:
I made this exact same suggestion some time ago (not in the context of PEP 572). Guido rejected it because it is easy (especially for newbies) to confuse for var in expr for var = expr I point out that the confusion is particularly acute in the cases such as for x = SomeTuple Rob Cliffe
This idea was mentioned (by me) at a time yes, but wasn't written in the document. I think one of the thing was that it would make the grammar non LL1 because when seeing the token "for" in a list comprehension it wouldn't know in advance if it's the loop or the assignment. And also, it might confuse people because 'for' is for iteration. Le jeu. 24 mai 2018 à 17:54, Alexander Belopolsky < alexander.belopolsky@gmail.com> a écrit :
On Thu, May 24, 2018 at 12:04 PM Robert Vanden Eynde <robertve92@gmail.com> wrote:
This idea was mentioned (by me) at a time yes, but wasn't written in the document.
Can you point me to a specific post? There were so may that I must have missed that one.
I don't see how that can be a problem. From the grammar point of view, "for" in "for var = <expr>" may still be seen as introducing a "loop", but when "=" is seen in place of "in", the compiler will resize that the "loop" is one a single value and emit efficient code for it. At the AST level, "for var = <expr>" will look exactly the same as "for var in <expr>" only with an "=" instead of "in".
And also, it might confuse people because 'for' is for iteration.
I think I addressed this in my previous post. Yes, for people with a C/C++ background, "for" may be too strongly associated with loops, but in mathematical sense, it seems clear that "for var in a set" means iteration over a set, while "for var = expression" means binding to a single value.
It was a long time ago I couldn't easily find the post but that's alright, you refreshed the idea :) Let's see what others think of for x = I also remembered some languages (like lua) use for x = range (5) interchangeably with for x in range (5) and guido said it will never make such a thing, for .. in being the iteration. Le jeu. 24 mai 2018 à 18:22, Alexander Belopolsky < alexander.belopolsky@gmail.com> a écrit :
I worry about the use of "for" because it will come up in contexts where "for" already has other meanings. In the case of the example list comprehension, the word "for" is being used to mean two entirely different things in a single expression, that seems rather precarious to me. I prefer "with" if we're looking for keywords to reuse. This feels fairly clean to me: [(x, y, x/y) for x in data with y = f(x) if y] if m with m = pattern.search(data): ... while m with m = pattern.search(remaining_data): ... Of course, "with" is not without problems and I'm not so happy about being able to: with open(a) as b with a = filename: ... --George On Thu, May 24, 2018 at 9:33 AM Robert Vanden Eynde <robertve92@gmail.com> wrote:
On Thu, May 24, 2018 at 11:54:09AM -0400, Alexander Belopolsky wrote:
C is well known for encouraging the "assignment instead of equals" error when people mistakenly use = when they mean ==. Instead of copying this design flaw, we'll have our own infamous design flaw: "assignment instead of looping" errors, when we mistakenly type "for var = thing" instead of "for var in thing" (or vice versa). Who says Python never innovates? :-) [...]
[(x, y, x/y) for x in data for y = f(x) if y]
[(x, y, x/y) for x in data if y := f(x)] In another post, you wrote: Yes, for people with a C/C++ background, "for" may be too strongly associated with loops, but in mathematical sense, it seems clear that "for var in a set" means iteration over a set, while "for var = expression" means binding to a single value. I don't come from a C/C++ background. I think "for" is strongly associated with loops in a large number of programming languages, including Python. http://rosettacode.org/wiki/Loops/For But I do have a mathematics background, and I don't remember ever seeing "for x = value" used in the sense you mean. I certainly wouldn't write that myself. I would expect to either: Given x = expression, then equation including x or the reverse order: equation including x where x = expression Normally I would only use "for" either in the context of sums, or the "for all" ∀ quantifier. (If that symbols doesn't show up, it is an upside down A.) -- Steve
But I do have a mathematics background, and I don't remember ever seeing "for x = value" used in the sense you mean.
That's so because in mathematics, "for" is spelled ":" as in {2*a* : *a*∈*Z*} If you can read the above, you should not have trouble reading {2*a* + *b* : *a*∈*Z *: *b = *1}
On Thu, May 24, 2018, 11:47 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Inverted "A" is "for all", and colon means "such that". It may be acceptable somewhere to use a colon as you do, but the lone colon unambiguously is "such that" when constructing sets. I never once saw colon used this way, and would be interested to see it in a proper math paper to correct my world view. "for" only reads as "such that" as: "A such that x = 1" "A, for x = 1" which sounds a bit Shakespearian and is definitely not common. standard math: "2a plus b for all integers such that b is 1." or "2a plus b for each integer such that b is 1" using "for" as ":": "2a plus b for a in integers for b in 1" or "2a plus b for a eauals integers for b eauals 1" or "2a plus b for all a in integers for all b in 1" Understandable, but I would get zero point on my homework for those, they are correct. In the context of math in general, ":=" makes more sense, and is actual math notation for assignment: http://mathworld.wolfram.com/Colon.html ignoring math: I'm kind of fine with nudging the meaning of "for" as you describe to be assignment, it's close enough, such that it's not a long leap. I think this point is the best case for "for", but I don't think being the only language to do this is great, and I usually don't care about language similarities. I lack breadth, however, so please correct me here. However, I cannot say this is superior to ":=" based on the same logic, as ":=" achieves the same ends with less semantic confusion, typing, and uses earlier indication of assignment. And please note that making "for" ambiguous when there is already the ambiguity in post fix notation makes the spelling less desirable to me. In this spelling, for one assignment, there are two ambiguities that must be resolved: the assigned name and the meaning of "for", though the latter is cleared up quickly. This small ambiguity is still there and I don't see a reason to introduce it. Thanks
On Thu, May 24, 2018 at 4:59 PM Matt Arcidy <marcidy@gmail.com> wrote:
See <https://en.wikipedia.org/wiki/Set_notation>. Also, "[list comprehensions] is Python's way of implementing a well-known notation for sets as used by mathematicians." < https://www.python-course.eu/list_comprehension.php>. Although, the latter uses "|" instead of ":".
On Thu, May 24, 2018, 14:48 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
My point was more along the lines of math doesn't use ":" for "for". "for" exists in math as a different symbol. Even in set builder notation ":" isn't interpretted as "for", it's "such that." Maybe the math discussion is totally tangential. I'm not clear why I'm making these points really, apologies if I took this off course, I'm happy to concede the math and just keep my other points. I don't think "for" is bad compared to some other alternatives, but I don't see it better than ":=" in the contexts you've raised. Even in the implementation of set building, "for" is only used to build the sets element wise, not as a partitioning, and is not a property if the set itself. Thanks,
On 24/05/2018 16:54, Alexander Belopolsky wrote:
I made this exact same suggestion some time ago (not in the context of PEP 572). Guido rejected it because it is easy (especially for newbies) to confuse for var in expr for var = expr I point out that the confusion is particularly acute in the cases such as for x = SomeTuple Rob Cliffe
participants (7)
-
Alexander Belopolsky -
George Leslie-Waksman -
Matt Arcidy -
Rob Cliffe -
Robert Vanden Eynde -
Serhiy Storchaka -
Steven D'Aprano