Re: Proposed new syntax
Steve D'Aprano writes: > What would you expect this syntax to return? > [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] [1,2,3] though the later example is more confusing. I don't think we need this since we have itertools.takewhile: from operator import gt from functools import partial from itertools import takewhile [x + 1 for x in takewhile(partial(gt,5), (0,1,2,999,3,4))] In the eye of the beholder maybe, but I think it's less ugly in Haskell: [x + 1 | x <- takeWhile (< 5) [0,1,2,999,3,4]] -- https://mail.python.org/mailman/listinfo/python-list
Re: Planning a Python Course for Beginners
Marko Rauhamaa wrote: Python : Marko Rauhamaa wrote: I didn't disagree with any of these statements about __hash__, but only your statement about id and __eq__: id() is actually an ideal return value of __hash__(). The only criterion is that the returned number should be different if the __eq__() is False. That is definitely true for id() nan is a clear, simple, undeniable counterexample to that claim. Still, I don't see the point you are trying to make. You do have a cognitive disease, don't you? -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
Ian Kelly writes:
> On Thu, Aug 10, 2017 at 8:28 AM, Steve D'Aprano
> wrote:
>> What would you expect this syntax to return?
>>
>> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
>
> I would expect the for to be an outer loop and the while to be an
> inner, so this would loop infinitely.
+1.
By the way, how is that supposed to be parsed? Is it (sorry for the
braces):
{for x in for x in (0, 1, 2, 999, 3, 4)} {while x < 5}
or
{for x in {(0, 1, 2, 999, 3, 4) while x < 5}}
I mean: would the "while ..." be another comp_iter [1], or be a
qualifier for an iterable/generator?
If the former, it doesn't make any sense unless you allow side-effects
in the comprehension's expression (as Ian pointed out), and this would
be a very bad idea. If the latter, it could make more sense, similar to
conditional expressions (but I still dislike it, and don't think such a
feature requires syntactic support).
-- Alain.
[1]
https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
10.08.17 17:28, Steve D'Aprano пише: Every few years, the following syntax comes up for discussion, with some people saying it isn't obvious what it would do, and others disagreeing and saying that it is obvious. So I thought I'd do an informal survey. What would you expect this syntax to return? [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] I would expect it to be equivalent to the following code: result = [] for x in (0, 1, 2, 999, 3, 4): while x < 5: result.append(x + 1) This is an infinite loop. For comparison, what would you expect this to return? (Without actually trying it, thank you.) [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5] result = [] for x in (0, 1, 2, 999, 3, 4): if x < 5: result.append(x + 1) How about these? [x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)] result = [] for x in (0, 1, 2, 999, 3, 4): while x < 5: for y in (100, 200): result.append(x + y) [x + y for x in (0, 1, 2, 999, 3, 4) if x < 5 for y in (100, 200)] result = [] for x in (0, 1, 2, 999, 3, 4): if x < 5: for y in (100, 200): result.append(x + y) -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
10.08.17 23:28, Ian Kelly пише: So, perhaps a better syntax could be: [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5 else break] (0, 1, 2, 999, 3, 4) if x < 5 else break looks too similar to the ternary operator. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
Serhiy Storchaka : > 10.08.17 17:28, Steve D'Aprano пише: >> What would you expect this syntax to return? >> >> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] > > I would expect it to be equivalent to the following code: > > result = [] > for x in (0, 1, 2, 999, 3, 4): > while x < 5: > result.append(x + 1) And I would expect this: result = [] for x in (0, 1, 2, 999, 3, 4): if not x < 5: break result.append(x + 1) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Planning a Python Course for Beginners
On 8/11/17 6:37 AM, Python wrote: > Marko Rauhamaa wrote: >> Python : >> >>> Marko Rauhamaa wrote: >>> I didn't disagree with any of these statements about __hash__, but only >>> your statement about id and __eq__: >>> id() is actually an ideal return value of __hash__(). The only criterion is that the returned number should be different if the __eq__() is False. That is definitely true for id() >>> >>> nan is a clear, simple, undeniable counterexample to that claim. >> >> Still, I don't see the point you are trying to make. > > You do have a cognitive disease, don't you? > > > Maybe it's time to just drop it, rather than starting to insult each other? --Ned. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On Fri, Aug 11, 2017 at 6:53 AM, Serhiy Storchaka wrote: > 10.08.17 23:28, Ian Kelly пише: >> >> So, perhaps a better syntax could be: >> >> [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5 else break] > > > (0, 1, 2, 999, 3, 4) if x < 5 else break > > looks too similar to the ternary operator. It is entirely intentional and a point in its favor, in my view, that "x + 1 ... if x < 5 else break" resembles the ternary operator, as it basically is a special syntax of that. But I take your point that it also resembles the ternary in "(0, 1, 2, 999, 3, 4) if x < 5 else break", which could lead to some confusion. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On 08/10/2017 11:29 PM, Steve D'Aprano wrote: > On Fri, 11 Aug 2017 12:54 pm, Mikhail V wrote: > >> but at a first glance, "while" reads as "if" as in english. > > In English the two words don't mean the same thing. But actually in some contexts they really do seem to mean the same thing: Make hay while the sun shines. If it's sunny, make hay. Essentially the same meaning, though we can argue whether "while" implies some kind of long-running activity that the if does not. Particularly people who are learning English may not even see the difference between while and if as far as a logical statement, similar to the ones above, goes. > > That's why > > if foo: > ... > > > and > > while foo: > ... > > > are different. In computer languages, sure. Spoken language is certainly not so clear cut. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On Thu, Aug 10, 2017 at 11:45 PM, Steve D'Aprano wrote: > On Fri, 11 Aug 2017 08:49 am, Ben Finney wrote: > >> The comprehension encourages thinking in sets: an operation that takes a >> collection as input, and emits a different collection, through one >> conceptual operation. >> >> Adding ‘while’ in there encourages thinking not in terms of a single >> set-based operation, but an iteration of separate operations. That >> confuses the model, and I no longer have a coherent model about which to >> reason what the syntax might mean. > > > Sorry Ben, you've completely lost me. > > If you had said that tradition functional style operations such as: > > map(func, iterable) > > filter(pred, iterable) > > "encourages thinking in sets: an operation that takes a collection as input, > and > emits a different collection, through one conceptual operation" > > then I would completely agree with you. I agree that is absolutely true: > traditional functional programming idioms encourage thinking of looping as a > single conceptual operation. For simplicity, both map() and filter() are often > implemented as a for loop that operates on one item at a time, in order, but > conceptually the map and filter could operate in parallel on all items at > once. > > But that's not the case for list comprehensions and generator expressions > (which > use almost exactly the same syntax). The sequential, one-item-at-a-time nature > isn't a mere implementation detail, it is an essential part of the semantics > of > the comprehension. > > Comprehension syntax makes the sequential loop explicit: the loop is right > there > in the syntax: > > [expr for x in iterable] This is a peculiarity of Python. Here's a list comprehension in Haskell, which has supported them since version 1.0 in 1990, much longer than Python: [x * 2 | x <- L, x * x > 3] The same thing in Erlang: [2*X || X <- L, X*X > 3] C#: var ns = from x in L where x*x > 3 select x*2; (Note "from", not "for") Scheme: (list-ec (: x 100) (if (> (* x x) 3)) (* x 2)) The grand-daddy of them all, NPL (which actually called them "set comprehensions" after mathematics): setofeven(X) <= <:x: x in X & even(x) :> Nothing about any of these suggests a loop or a requirement for serial processing. Granted, there are other languages I've not listed here that use loop syntax like Python. >> Though ‘for’ is used elsewhere in Python to mean iteration, ‘for’ also >> has strong connotation in mathematics for set-based operations (“the >> result is foo for all bar, if baz”). So the same confusion doesn't >> occur: this is a comprehension which is about set-based thinking, which >> is supported by all the semantic connotations of the syntax. > > I don't understand this. I *think* what you're saying is "I have internalised > the explicit for-loop and think of it as a filter plus a map and no longer > think of it as a for-loop", but I'm not sure. More like, "Python has externalized the list comprehension as a for loop despite the rich tradition to the contrary." -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
Steve D'Aprano writes: > Every few years, the following syntax comes up for discussion, with some > people > saying it isn't obvious what it would do, and others disagreeing and saying > that it is obvious. So I thought I'd do an informal survey. > > What would you expect this syntax to return? > > [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] > > For comparison, what would you expect this to return? (Without actually trying > it, thank you.) > > [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5] These are not unclear (I think I'd guess that same as most people) but adding a new while clause, and the existing if clause, both seem to be rather narrow solutions. The general solution would be to filter the iterable (if that's the right term for it). In Haskell: [x+1 | x <- takeWhile (<5) [0, 1, 2, 999, 3, 4]] [x+1 | x <- filter(<5) [0, 1, 2, 999, 3, 4]] I am sure you can already do this in Python but presumably it's not convenient or there would be little incentive to build "takeWhile" into the language. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On Sat, 12 Aug 2017 12:45 am, Michael Torrie wrote: > On 08/10/2017 11:29 PM, Steve D'Aprano wrote: >> On Fri, 11 Aug 2017 12:54 pm, Mikhail V wrote: >> >>> but at a first glance, "while" reads as "if" as in english. >> >> In English the two words don't mean the same thing. > But actually in some contexts they really do seem to mean the same thing: > > Make hay while the sun shines. > If it's sunny, make hay. > > Essentially the same meaning, though we can argue whether "while" > implies some kind of long-running activity that the if does not. We really shouldn't argue about that, because that is the crux of the difference. If \If\, conj. 1. In case that; granting, allowing, or supposing that; -- introducing a condition or supposition. [1913 Webster] While \While\, conj. 1. During the time that; as long as; whilst; at the same time that; as, while I write, you sleep. "While I have time and space." --Chaucer. [1913 Webster] Of course there is overlap: both are conjunctions, both depend on a condition, but the fundamental difference is that of duration. Your two examples are not actually equivalent: "Make hay while the sun shines" implies that making hay is a process you can continue for as long as the sun continues to shine; "If it's sunny, make hay" implies that making hay is a once-off job that you do once, provided it is sunny, and then go on to do other things even if it remains sunny. And that is why the English proverb is the first, not the second. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On Friday, August 11, 2017 at 8:33:32 PM UTC+5:30, Ian wrote:
> The grand-daddy of them all, NPL (which actually called them "set
> comprehensions" after mathematics):
>
> setofeven(X) <= <:x: x in X & even(x) :>
Thanks for reminding of NPL; will add it to my history summary at
http://blog.languager.org/2015/04/cs-history-1.html
>
>
> Nothing about any of these suggests a loop or a requirement for serial
> processing. Granted, there are other languages I've not listed here
> that use loop syntax like Python.
>
>
> >> Though ‘for’ is used elsewhere in Python to mean iteration, ‘for’ also
> >> has strong connotation in mathematics for set-based operations (“the
> >> result is foo for all bar, if baz”). So the same confusion doesn't
> >> occur: this is a comprehension which is about set-based thinking, which
> >> is supported by all the semantic connotations of the syntax.
> >
> > I don't understand this. I *think* what you're saying is "I have
> > internalised
> > the explicit for-loop and think of it as a filter plus a map and no longer
> > think of it as a for-loop", but I'm not sure.
>
> More like, "Python has externalized the list comprehension as a for
> loop despite the rich tradition to the contrary."
Very true.
Like Occam's razor, we have a Guido-razor "Minimize new keywords” which helps
compatibility across language versions but not comprehension (of not just
comprehensions!)
Actually list comprehensions go further than NPL to SETL except that they were
called ‘set-formers’ not ‘set-comprehensions'
[ My conjecture: The word ‘comprehension’ used this way in English is
meaningless and is probably an infelicious translation of something which makes
sense in German]
Interestingly from the SETL manual [4 page 22] about Set-formers in SETL (SETL
term for set-comprehension)
“The SETL iterator has exactly the same form as a loop iterator,
except that the keyword for is omitted”
History-Capsule (as I understand it):
List comprehensions in python (2.0 c. 2000) come from haskell [1] [2]
Haskell (c. 1990) got it from Miranda
Miranda (c. 1980) got it from SETL [4]
SETL (c. 1960) main innovation was sets, sequences and 'set-builder notation'
whose SETL name was 'set-former' nowadays called comprehension notation
SETL, as best as I know, is the first computer language using the math notation
… which itself goes back to Zermelo (c. 1930) who gave his axiomatization for
set theory…
…Containing the comprehension-axiom [3]
…Which was needed to avoid problems like Russell's paradox
R = {x | x ∉ x}
is disallowed, since allows to directly derive the contradiction
R∉R iff R∈R
So the axiom-of-comprehension mandated by Zermelo/Fraenkel is that one must
define R from some previous set P
R = {x ∈ P | x ∉ x}
which in more programmerish notation becomes
R = {x | x ∈ P, x ∉ x}
which renders the x ∉ x harmless
Or more pythonically:
R = {x for x in P if x not in x}
[1] https://docs.python.org/3/whatsnew/2.0.html
[2] https://docs.python.org/3/howto/functional.html
[3] https://en.wikipedia.org/wiki/Axiom_schema_of_specification
[4] http://cs.nyu.edu/~bacon/setl/doc-legacy/setlprog.pdf
--
https://mail.python.org/mailman/listinfo/python-list
